Re: #pragma once
Well..h files are a crock to begin with. You can always do stuff like: *#include "bunch_of_constants_you_will_need.c"* Still C is a crock. The preprocessor is a crock. The 'macro' system is a crock. And the language is a crock. (it's from New Jersey, I'm told...) Rather than small proposed changes like this -- what about moving to a more modern language (Rust?). So these types of trivialities are not even conceptualized. -mac On Mon, Oct 24, 2022 at 1:05 AM Robert Elz wrote: > Date:Sun, 23 Oct 2022 09:50:20 + > From:Taylor R Campbell > Message-ID: <20221023095027.eb8ef60...@jupiter.mumble.net> > > | I wasn't able to find a clear statement of the semantics anywhere: > | Is it keyed by (dev,ino), by pathname, by some kind of normalized > | pathname, by file content? gcc's own documentation is very sparse and > | just describes it as nonportable. > > I had not weighed in on this before, but that issue was the biggest > problem I could see with this. > > That and that using guards allows having mutually exclusive (but > different) include files ... though of course they could always be > used for any such cases even if the #pragma scheme became the normal > way. > > | So on balance, #pragma once doesn't seem worthwhile to me today, and > | I think we should stick to traditional include guards for now. > > I agree. > > kre > > >
Re: #pragma once
Date:Sun, 23 Oct 2022 09:50:20 + From:Taylor R Campbell Message-ID: <20221023095027.eb8ef60...@jupiter.mumble.net> | I wasn't able to find a clear statement of the semantics anywhere: | Is it keyed by (dev,ino), by pathname, by some kind of normalized | pathname, by file content? gcc's own documentation is very sparse and | just describes it as nonportable. I had not weighed in on this before, but that issue was the biggest problem I could see with this. That and that using guards allows having mutually exclusive (but different) include files ... though of course they could always be used for any such cases even if the #pragma scheme became the normal way. | So on balance, #pragma once doesn't seem worthwhile to me today, and | I think we should stick to traditional include guards for now. I agree. kre
Re: #pragma once
> Date: Sat, 15 Oct 2022 19:21:35 + > From: Taylor R Campbell > > #pragma once > [...] > How reliable/consistent is toolchain support for it? Is it worth > adopting or is the benefit negligible over continuing to use > traditional #include guards? Likely problems with adopting it? I wasn't able to find a clear statement of the semantics anywhere: Is it keyed by (dev,ino), by pathname, by some kind of normalized pathname, by file content? gcc's own documentation is very sparse and just describes it as nonportable. I spent a few minutes skimming the code in gcc and it wasn't obvious to me except that it might be indexed by MD5 hash of file content which would be unnerving (unless that's just for precompiled header files or something, didn't spend enough time to be sure). The value seems negligible: clang detects mismatched include guards in a single .h file, which leaves only the problem of overlapping include guards, but it wouldn't be hard with grep to detect that or even teach lint to enforce include guard naming rules. So on balance, #pragma once doesn't seem worthwhile to me today, and I think we should stick to traditional include guards for now.
Re: #pragma once
Am Sat, Oct 15, 2022 at 07:21:35PM + schrieb Taylor R Campbell: > How reliable/consistent is toolchain support for it? Is it worth > adopting or is the benefit negligible over continuing to use > traditional #include guards? Likely problems with adopting it? Does it gain anything beside a tiny bit smaller? I don't think it is faster and trading three lines of boilerplate per header file for a non-portable construct is a worthy gain. Joerg
Re: #pragma once
My quick reaction is that we should stick to actual standards, absent a really compelling case. This isn't compelling to me, and the point that linting for wrong usage isn't hard is a good one. I happen to be in the middle of a paper (from the guix crowd) about de-boostrapping ocaml. It's about getting rid of binary bootstraps. That's a problem we also have in pkgsrc, but we haven't issued a manifesto. While it might seem tangential, the de-bootstrapping world often wants to compile older code with older tools to construct a build graph that starts from as little binary as possible. Thus, "newer compilers all do this" is a bit scary, as while that's what people usually use, it's more comfortable to say "we need C99 plus X" for as little X as possible. signature.asc Description: PGP signature
Re: #pragma once
Den 2022-10-16 kl. 00:17, skrev matthew green: it seems that pcc is missing '#pragma once' support. at least, the version in src. ragge, can you fix it? :-) thanks. Hehe :-) No problem, should be close to trivial. I think best way to detect the same file would be to just save the inode (and device) of a "once" file. -- R
Re: #pragma once
Mouse wrote in <202210152055.qaa24...@stone.rodents-montreal.org>: |> Traditionally to avoid problems with repeated inclusion of a header |> file, you put #include guards around it, say in sys/dev/foo.h: |> [...] | |> With newer compilers this can be replaced by a single line in the |> header file: | |> #pragma once | |Some newer compilers, perhaps. Unless and until it is standardized, tcc yes, pcc not. ... |> It's nonstandard, but using #pragma once is maybe a bit less |> error-prone -- don't have to have to pollute the namespace with Wow. I have never seen such an error. (In fact _i_ use multiple inclusions consciously in a number of places, and have always done so. This would not change, of course.) If it would have been a different poster i would have thought it is April 1st, actually. #pragma once. Hey. It is a good thing. I think it would have been cool to have it twenty years ago, most of you would surely agree more so a decade or two earlier even. Somehow they must have missed to implement it in the 70s. (I personally struggle with #?0|kent:pcc.git$ xz -l /usr/ports/built/tcc#20220817-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1239.1 KiB 1149.5 KiB 0.208 CRC64 /usr/ports/built/tcc#20220817-1.pkg.tar.xz #?0|kent:pcc.git$ xz -l /usr/ports/built/gcc#12.2.0-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 47.6 MiB204.9 MiB 0.232 CRC64 /usr/ports/built/gcc#12.2.0-1.pkg.tar.xz #?0|kent:pcc.git$ xz -l /usr/ports/built/clang#15.0.2-1.pkg.tar.xz Strms Blocks Compressed Uncompressed Ratio Check Filename 1 1 90.8 MiB945.9 MiB 0.096 CRC64 /usr/ports/built/clang#15.0.2-1.pkg.tar.xz #?0|kent:pcc.git$ but likely i am addressing the wrong people.) A nice Sunday everybody. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: #pragma once
On Sun, Oct 16, 2022 at 06:31:55AM +1100, matthew green wrote: > note that it is already used in libpcap, bind, libuv, and as a > test for xlint, in our tree, for consumed components. hmm? % grep 'pragma.*once' /usr/include/**.h % also, while it does appear (once) inside libuv, that's within a _MSC_VER conditional. -- David A. Holland dholl...@netbsd.org
re: #pragma once
it seems that pcc is missing '#pragma once' support. at least, the version in src. ragge, can you fix it? :-) thanks. .mrg.
Re: #pragma once
On Sat, Oct 15, 2022 at 07:21:35PM +, Taylor R Campbell wrote: > [bcc tech-userlevel tech-toolchain, followups on tech-kern] > > Traditionally to avoid problems with repeated inclusion of a header > file, you put #include guards around it, say in sys/dev/foo.h: > > #ifndef _SYS_DEV_FOO_H_ > #define _SYS_DEV_FOO_H_ > > ... > > #endif /* _SYS_DEV_FOO_H_ */ > > With newer compilers this can be replaced by a single line in the > header file: > > #pragma once > > It's nonstandard, but using #pragma once is maybe a bit less > error-prone -- don't have to have to pollute the namespace with > have-I-been-included macros, and I've made mistakes with copying & > pasting the per-file have-I-been-included macro into the wrong file. I don't see any benefit given that it's maybe 5-10 minutes with sed to write a script to detect wrong include guards. Furthermore since we still don't have a clear separation between internal and user-facing kernel headers, there's no significant place we can safely/correctly use the pragma that will help much. -- David A. Holland dholl...@netbsd.org
Re: #pragma once
> Traditionally to avoid problems with repeated inclusion of a header
> file, you put #include guards around it, say in sys/dev/foo.h:
> [...]
> With newer compilers this can be replaced by a single line in the
> header file:
> #pragma once
Some newer compilers, perhaps. Unless and until it is standardized,
there's no telling what #pramga once might mean to the next compiler to
come along - except that, for Eliza reasons, it presumably will be
related to doing something only once, but there are a lot of such
possibilities.
Furthermore, even when implementors agree on the basic meaning, unless
and until it is precisely specified and standardized, implementations
will differ in corner cases.
foo.h
#define FOO(x) _Pragma(x)
bar.h
#define BAR() FOO("once")
hdr.h
#include "bar.h"
#include "foo.h"
BAR()
Which file gets the include-once semantic? Why or why not? I could
make an argument for each of the three (some of the arguments will be
stronger than others...but which ones are which will vary by person).
> It's nonstandard, but using #pragma once is maybe a bit less
> error-prone -- don't have to have to pollute the namespace with
> have-I-been-included macros, and I've made mistakes with copying &
> pasting the per-file have-I-been-included macro into the wrong file.
I'm not sure. I see arguments each way.
The biggest problems I see with using it in NetBSD-provided include
files:
(1) Developers may see it and think it's more portable than it is as a
result. Developers are already way too ready to assume that anything
that works on their development machines is suitable for release.
(2) Unless and until the functionality is standardized, it makes the
system gratuitously nonportable. ("Portable between what I think are
the currently most popular two compilers" is awfully weak, even if
"what I think" is correct.)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
re: #pragma once
On Sun, 16 Oct 2022, matthew green wrote: i am a fan of #pragma once. the main reason is that it avoids the class of bugs where you copy a header and forget to change the #define and then sometimes the header is empty upon use, and you end up having to use cpp output to debug it. I've been bit more than once here... i'd be ok with using it anywhere -- AFAIK the compiler support is available everywhere. me too ++--+--+ | Paul Goyette | PGP Key fingerprint: | E-mail addresses:| | (Retired) | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com| | Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org | | & Network Engineer | | pgoyett...@gmail.com | ++--+--+
re: #pragma once
i am a fan of #pragma once. the main reason is that it avoids the class of bugs where you copy a header and forget to change the #define and then sometimes the header is empty upon use, and you end up having to use cpp output to debug it. i'd be ok with using it anywhere -- AFAIK the compiler support is available everywhere. note that it is already used in libpcap, bind, libuv, and as a test for xlint, in our tree, for consumed components. .mrg.
