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.
#pragma once
[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. That said, clang has a warning these days to detect this mistake so maybe traditional #include guards aren't that error-prone. Thoughts on its use in NetBSD in: (a) purely internal header files? (b) header files exposed to potentially out-of-tree kernel modules? (c) header files exposed to userland? 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?
