Re: #pragma once (was Re: incoming)
On Sat, Feb 27, 2021 at 02:02:21AM +0300, Alexey Dobriyan wrote: > There are rules and schemes about how to create guard macro. > > Should it be prefixed by underscore? > Should it be prefixed by two underscores? > Should it be full path uppercased or just last path component? > Should the guard macro be lowercased? > Should it be changed when header is moved? > Should trailing #endif contain comment? > Should #define be just #define or "#define FOO 1"? Who cares? To all of the above, really. > I've even seen advice (or an IDE doing that) that is should contain > timestamp of a header creation time to minimise collisions (implying > collisions could happen as could typos as could broken guards) Ever seen that in the tree? Where, if so? > All this zoo of styles and made up mental work is completely avoided > by using #pragma once: > > 1) put #pragma once on the first line > > or > > 2) put #pragma once on the second line after SPDX banner > > and that's it. > > No fuss, no filled up preprocessor hashtables, no implicit arguing > about styles. Care to provide some stats on the amount of those macros encountered on build, along with the total amount of defines parsed and hashed? It's noise. And what is "implicit arguing", BTW? I'm yet to see any fights along those lines - you are the first one to bring that up, AFAICS. Maybe I'd simply been lucky until now, of course, but...
RE: #pragma once (was Re: incoming)
From: Alexey Dobriyan > Sent: 26 February 2021 23:02 > > On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote: > > On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan > > wrote: > > > > > > I want to sent treewide "#pragma once" conversion: > > > > Are there *any* advantages to it? > > > > It's non-standard, > > It is effectively standard: > https://en.wikipedia.org/wiki/Pragma_once#Portability At the top of the page In the C and C++ programming languages, pragma once is a non-standard but widely supported So non-standard :-) And #pragma is ugly... There are also times when an include guard has to be set in order to stop a problematic inner file being included. Perhaps only during hacking, but it is useful. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)
Re: #pragma once (was Re: incoming)
On Fri, Feb 26, 2021 at 01:53:48PM -0800, Linus Torvalds wrote:
> On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan wrote:
> >
> > I want to sent treewide "#pragma once" conversion:
>
> Are there *any* advantages to it?
>
> It's non-standard,
It is effectively standard:
https://en.wikipedia.org/wiki/Pragma_once#Portability
and I'll spare UAPI headers from conversion.
> and the historical argument for it ("it can reduce
> compile times because the preprocessor doesn't open the file twice" is
> pure and utter hogwash. Any preprocessor worth its salt does the same
> thing for the standard and traditional #ifndef/#define guard sequence.
>
> Honestly, "#pragma once" was always a hack for bad preprocessors that
> weren't smart enough to just figure it out from the regular guarding
> macros.
>
> I can't imagine that any preprocessor that incompetent exists any
> more, and if i does, we sure shouldn't be using it.
>
> So #pragma once seems to have no actual advantages.
The advantage is removing busywork that is include guards.
There are rules and schemes about how to create guard macro.
Should it be prefixed by underscore?
Should it be prefixed by two underscores?
Should it be full path uppercased or just last path component?
Should the guard macro be lowercased?
Should it be changed when header is moved?
Should trailing #endif contain comment?
Should #define be just #define or "#define FOO 1"?
I've even seen advice (or an IDE doing that) that is should contain
timestamp of a header creation time to minimise collisions (implying
collisions could happen as could typos as could broken guards)
All this zoo of styles and made up mental work is completely avoided
by using #pragma once:
1) put #pragma once on the first line
or
2) put #pragma once on the second line after SPDX banner
and that's it.
No fuss, no filled up preprocessor hashtables, no implicit arguing
about styles. And way less LOC:
18092 files changed, 18883 insertions(+), 99841 deletions(-)
Now if old school header guard is necessary it can be used like in
good old times.
Nobody would miss include guards.
Re: #pragma once (was Re: incoming)
On Fri, Feb 26, 2021 at 12:17 PM Alexey Dobriyan wrote:
>
> I want to sent treewide "#pragma once" conversion:
Are there *any* advantages to it?
It's non-standard, and the historical argument for it ("it can reduce
compile times because the preprocessor doesn't open the file twice" is
pure and utter hogwash. Any preprocessor worth its salt does the same
thing for the standard and traditional #ifndef/#define guard sequence.
Honestly, "#pragma once" was always a hack for bad preprocessors that
weren't smart enough to just figure it out from the regular guarding
macros.
I can't imagine that any preprocessor that incompetent exists any
more, and if i does, we sure shouldn't be using it.
So #pragma once seems to have no actual advantages.
Linus
Re: #pragma once?
On Sun, Jan 12, 2014 at 11:14:56AM -0500, Patrick Palka wrote: > On Mon, Jan 6, 2014 at 3:47 PM, Josh Triplett wrote: > > Does anyone have any objection to the use of "#pragma once" instead of > > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > > and the latest Sparse all support either method just fine. (I added > > support to Sparse myself.) Both have equivalent performance. "#pragma > > once" is simpler, and avoids the possibility of a typo in the defined > > guard symbol. > > Unfortunately in GCC #pragma once is slower and slightly buggier than > regular include guards: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 The bug in question doesn't seem to apply to any likely use in the Linux kernel. As for performance, that benchmark seems somewhat odd to me, and I'm not entirely convinced that it's representative of real-world projects, which don't typically include ten thousand include files in one compilation. I've benchmarked the case of a single main.c including a single guarded.h with both types of guards, and found the two guard types indistinguishable in performance. Beyond that, I'd say real-world benchmarks would be preferable to artificial ones before declaring a performance difference between the two types of guards. - Josh Trpilett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 6, 2014 at 3:47 PM, Josh Triplett wrote: > Does anyone have any objection to the use of "#pragma once" instead of > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > and the latest Sparse all support either method just fine. (I added > support to Sparse myself.) Both have equivalent performance. "#pragma > once" is simpler, and avoids the possibility of a typo in the defined > guard symbol. Unfortunately in GCC #pragma once is slower and slightly buggier than regular include guards: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 6, 2014 at 3:47 PM, Josh Triplett j...@joshtriplett.org wrote: Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, and the latest Sparse all support either method just fine. (I added support to Sparse myself.) Both have equivalent performance. #pragma once is simpler, and avoids the possibility of a typo in the defined guard symbol. Unfortunately in GCC #pragma once is slower and slightly buggier than regular include guards: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Sun, Jan 12, 2014 at 11:14:56AM -0500, Patrick Palka wrote: On Mon, Jan 6, 2014 at 3:47 PM, Josh Triplett j...@joshtriplett.org wrote: Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, and the latest Sparse all support either method just fine. (I added support to Sparse myself.) Both have equivalent performance. #pragma once is simpler, and avoids the possibility of a typo in the defined guard symbol. Unfortunately in GCC #pragma once is slower and slightly buggier than regular include guards: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52566 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58770 The bug in question doesn't seem to apply to any likely use in the Linux kernel. As for performance, that benchmark seems somewhat odd to me, and I'm not entirely convinced that it's representative of real-world projects, which don't typically include ten thousand include files in one compilation. I've benchmarked the case of a single main.c including a single guarded.h with both types of guards, and found the two guard types indistinguishable in performance. Beyond that, I'd say real-world benchmarks would be preferable to artificial ones before declaring a performance difference between the two types of guards. - Josh Trpilett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Tue, Jan 07, 2014 at 10:48:53AM +0100, Geert Uytterhoeven wrote: > On Tue, Jan 7, 2014 at 6:55 AM, Sam Ravnborg wrote: > > On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: > >> [CCing build-system folks and others likely to know about potential > >> issues.] > >> > >> Does anyone have any objection to the use of "#pragma once" instead of > >> the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > >> and the latest Sparse all support either method just fine. (I added > >> support to Sparse myself.) Both have equivalent performance. "#pragma > >> once" is simpler, and avoids the possibility of a typo in the defined > >> guard symbol. > > For kernel headers no concern. > > Just being cautious: > > Do we know the minimum gcc version that supports #pragma once? >From checking the manuals, it goes back to at least 2.95. Searching suggests that versions before 3.4 have a few bugs in "#pragma once" support, but that those bugs only apply to using #pragma once in combination with precompiled headers, which doesn't apply to the kernel. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Tue, Jan 07, 2014 at 11:09:11AM +0100, Michal Marek wrote: > On 2014-01-07 10:48, Geert Uytterhoeven wrote: > > Furthermore some userspace may rely on doing #define XXX to avoid > > including a specific kernel header (yes, it's ugly). > > This pattern is also sometimes used: > $ head -6 include/linux/spinlock_up.h > #ifndef __LINUX_SPINLOCK_UP_H > #define __LINUX_SPINLOCK_UP_H > > #ifndef __LINUX_SPINLOCK_H > # error "please don't include this file directly" > #endif > > And there is nothing ugly about it. That's debatable, but it's certainly reasonable to try to enforce non-inclusion of "internal" headers directly. However, for headers not exposed to userspace, it'd be easy to write that as: include/linux/spinlock.h: #pragma once #define LINUX_SPINLOCK_H_INCLUDED include/linux/spinlock_up.h: #pragma once #ifndef LINUX_SPINLOCK_H_INCLUDED #error "Only include this file via spinlock.h, never directly" #endif > So #pragma once is probably a good > idea for most headers that are not exposed to userspace. But making it a > requirement in scripts/checkpatch.pl or Documentation/CodingStyle means > that it will become hard to defend the few legitimate uses of ifndef > guards against people who have a printed copy of checkpatch.pl under > their pillow. Any mention in CodingStyle or check in checkpatch would need to cover the two exceptions: uapi, and headers that are intentionally parsed multiple times for preprocessor magic (TRACE_HEADER_MULTI_READ). - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On 2014-01-07 10:48, Geert Uytterhoeven wrote: > Furthermore some userspace may rely on doing #define XXX to avoid > including a specific kernel header (yes, it's ugly). This pattern is also sometimes used: $ head -6 include/linux/spinlock_up.h #ifndef __LINUX_SPINLOCK_UP_H #define __LINUX_SPINLOCK_UP_H #ifndef __LINUX_SPINLOCK_H # error "please don't include this file directly" #endif And there is nothing ugly about it. So #pragma once is probably a good idea for most headers that are not exposed to userspace. But making it a requirement in scripts/checkpatch.pl or Documentation/CodingStyle means that it will become hard to defend the few legitimate uses of ifndef guards against people who have a printed copy of checkpatch.pl under their pillow. Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Tue, Jan 7, 2014 at 6:55 AM, Sam Ravnborg wrote:
> On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote:
>> [CCing build-system folks and others likely to know about potential
>> issues.]
>>
>> Does anyone have any objection to the use of "#pragma once" instead of
>> the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang,
>> and the latest Sparse all support either method just fine. (I added
>> support to Sparse myself.) Both have equivalent performance. "#pragma
>> once" is simpler, and avoids the possibility of a typo in the defined
>> guard symbol.
> For kernel headers no concern.
Just being cautious:
Do we know the minimum gcc version that supports #pragma once?
Furthermore I found this:
| #pragma once does have one drawback (other than being non-standard) and
| that is if you have the same file in different locations then the
compiler will
| think these are different files.
http://stackoverflow.com/questions/787533/is-pragma-once-a-safe-include-guard
With asm-generic and uapi, do we have multiple header files that
deliberately use the same include guards?
I know we have header files that deliberately don't have include guards
(e.g. asm/unistd.h on some architectures).
> For UAPI headers we should be more carefull - as we do not know which
> compiler it ends up seeing - and what version.
Furthermore some userspace may rely on doing #define XXX to avoid
including a specific kernel header (yes, it's ugly).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Tue, Jan 7, 2014 at 6:55 AM, Sam Ravnborg s...@ravnborg.org wrote:
On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote:
[CCing build-system folks and others likely to know about potential
issues.]
Does anyone have any objection to the use of #pragma once instead of
the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang,
and the latest Sparse all support either method just fine. (I added
support to Sparse myself.) Both have equivalent performance. #pragma
once is simpler, and avoids the possibility of a typo in the defined
guard symbol.
For kernel headers no concern.
Just being cautious:
Do we know the minimum gcc version that supports #pragma once?
Furthermore I found this:
| #pragma once does have one drawback (other than being non-standard) and
| that is if you have the same file in different locations then the
compiler will
| think these are different files.
http://stackoverflow.com/questions/787533/is-pragma-once-a-safe-include-guard
With asm-generic and uapi, do we have multiple header files that
deliberately use the same include guards?
I know we have header files that deliberately don't have include guards
(e.g. asm/unistd.h on some architectures).
For UAPI headers we should be more carefull - as we do not know which
compiler it ends up seeing - and what version.
Furthermore some userspace may rely on doing #define XXX to avoid
including a specific kernel header (yes, it's ugly).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On 2014-01-07 10:48, Geert Uytterhoeven wrote: Furthermore some userspace may rely on doing #define XXX to avoid including a specific kernel header (yes, it's ugly). This pattern is also sometimes used: $ head -6 include/linux/spinlock_up.h #ifndef __LINUX_SPINLOCK_UP_H #define __LINUX_SPINLOCK_UP_H #ifndef __LINUX_SPINLOCK_H # error please don't include this file directly #endif And there is nothing ugly about it. So #pragma once is probably a good idea for most headers that are not exposed to userspace. But making it a requirement in scripts/checkpatch.pl or Documentation/CodingStyle means that it will become hard to defend the few legitimate uses of ifndef guards against people who have a printed copy of checkpatch.pl under their pillow. Michal -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Tue, Jan 07, 2014 at 11:09:11AM +0100, Michal Marek wrote: On 2014-01-07 10:48, Geert Uytterhoeven wrote: Furthermore some userspace may rely on doing #define XXX to avoid including a specific kernel header (yes, it's ugly). This pattern is also sometimes used: $ head -6 include/linux/spinlock_up.h #ifndef __LINUX_SPINLOCK_UP_H #define __LINUX_SPINLOCK_UP_H #ifndef __LINUX_SPINLOCK_H # error please don't include this file directly #endif And there is nothing ugly about it. That's debatable, but it's certainly reasonable to try to enforce non-inclusion of internal headers directly. However, for headers not exposed to userspace, it'd be easy to write that as: include/linux/spinlock.h: #pragma once #define LINUX_SPINLOCK_H_INCLUDED include/linux/spinlock_up.h: #pragma once #ifndef LINUX_SPINLOCK_H_INCLUDED #error Only include this file via spinlock.h, never directly #endif So #pragma once is probably a good idea for most headers that are not exposed to userspace. But making it a requirement in scripts/checkpatch.pl or Documentation/CodingStyle means that it will become hard to defend the few legitimate uses of ifndef guards against people who have a printed copy of checkpatch.pl under their pillow. Any mention in CodingStyle or check in checkpatch would need to cover the two exceptions: uapi, and headers that are intentionally parsed multiple times for preprocessor magic (TRACE_HEADER_MULTI_READ). - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Tue, Jan 07, 2014 at 10:48:53AM +0100, Geert Uytterhoeven wrote: On Tue, Jan 7, 2014 at 6:55 AM, Sam Ravnborg s...@ravnborg.org wrote: On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: [CCing build-system folks and others likely to know about potential issues.] Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, and the latest Sparse all support either method just fine. (I added support to Sparse myself.) Both have equivalent performance. #pragma once is simpler, and avoids the possibility of a typo in the defined guard symbol. For kernel headers no concern. Just being cautious: Do we know the minimum gcc version that supports #pragma once? From checking the manuals, it goes back to at least 2.95. Searching suggests that versions before 3.4 have a few bugs in #pragma once support, but that those bugs only apply to using #pragma once in combination with precompiled headers, which doesn't apply to the kernel. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: > [CCing build-system folks and others likely to know about potential > issues.] > > Does anyone have any objection to the use of "#pragma once" instead of > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > and the latest Sparse all support either method just fine. (I added > support to Sparse myself.) Both have equivalent performance. "#pragma > once" is simpler, and avoids the possibility of a typo in the defined > guard symbol. For kernel headers no concern. For UAPI headers we should be more carefull - as we do not know which compiler it ends up seeing - and what version. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 04:33:49PM -0500, Theodore Ts'o wrote: > On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: > > Does anyone have any objection to the use of "#pragma once" instead of > > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > > and the latest Sparse all support either method just fine. (I added > > support to Sparse myself.) Both have equivalent performance. "#pragma > > once" is simpler, and avoids the possibility of a typo in the defined > > guard symbol. > > Does anybody know whether other static code analysis tools such as > Coverity can handle #pragma once? Coverity should be fine. If it does break, I'm sure they'd fix it. Dave -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: > Does anyone have any objection to the use of "#pragma once" instead of > the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, > and the latest Sparse all support either method just fine. (I added > support to Sparse myself.) Both have equivalent performance. "#pragma > once" is simpler, and avoids the possibility of a typo in the defined > guard symbol. Does anybody know whether other static code analysis tools such as Coverity can handle #pragma once? - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 01:00:03PM -0800, Andrew Morton wrote: > On Mon, 6 Jan 2014 12:47:07 -0800 Josh Triplett wrote: > > > Does anyone have any objection to the use of "#pragma once" instead of > > the usual #ifndef-#define-...-#endif include guard? > > Sounds OK to me. gcc has supported this for quite a long time, yes? I > wonder if ICC supports it. Yes, ICC supports it as well, if anyone cares. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, 6 Jan 2014 12:47:07 -0800 Josh Triplett wrote: > Does anyone have any objection to the use of "#pragma once" instead of > the usual #ifndef-#define-...-#endif include guard? Sounds OK to me. gcc has supported this for quite a long time, yes? I wonder if ICC supports it. (I haven't heard anything of ICC-for-kernel in a long time - is it still a living thing?) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, 6 Jan 2014 12:47:07 -0800 Josh Triplett j...@joshtriplett.org wrote: Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? Sounds OK to me. gcc has supported this for quite a long time, yes? I wonder if ICC supports it. (I haven't heard anything of ICC-for-kernel in a long time - is it still a living thing?) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 01:00:03PM -0800, Andrew Morton wrote: On Mon, 6 Jan 2014 12:47:07 -0800 Josh Triplett j...@joshtriplett.org wrote: Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? Sounds OK to me. gcc has supported this for quite a long time, yes? I wonder if ICC supports it. Yes, ICC supports it as well, if anyone cares. - Josh Triplett -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, and the latest Sparse all support either method just fine. (I added support to Sparse myself.) Both have equivalent performance. #pragma once is simpler, and avoids the possibility of a typo in the defined guard symbol. Does anybody know whether other static code analysis tools such as Coverity can handle #pragma once? - Ted -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 04:33:49PM -0500, Theodore Ts'o wrote: On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, and the latest Sparse all support either method just fine. (I added support to Sparse myself.) Both have equivalent performance. #pragma once is simpler, and avoids the possibility of a typo in the defined guard symbol. Does anybody know whether other static code analysis tools such as Coverity can handle #pragma once? Coverity should be fine. If it does break, I'm sure they'd fix it. Dave -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: #pragma once?
On Mon, Jan 06, 2014 at 12:47:07PM -0800, Josh Triplett wrote: [CCing build-system folks and others likely to know about potential issues.] Does anyone have any objection to the use of #pragma once instead of the usual #ifndef-#define-...-#endif include guard? GCC, LLVM/clang, and the latest Sparse all support either method just fine. (I added support to Sparse myself.) Both have equivalent performance. #pragma once is simpler, and avoids the possibility of a typo in the defined guard symbol. For kernel headers no concern. For UAPI headers we should be more carefull - as we do not know which compiler it ends up seeing - and what version. Sam -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
