Re: [PATCH 10/11] pragma once: delete few backslashes

Hi! > > index e201b4b1655a..46704c341b17 100644 > > --- a/arch/arc/include/asm/cacheflush.h > > +++ b/arch/arc/include/asm/cacheflush.h > > @@ -112,6 +112,6 @@ do { > > \ > > } while (0) > > > > #define

Re: [PATCH 00/11] pragma once: treewide conversion

Hi! > > > (a) the traditional include guard optimization HAS NO HIDDEN SEMANTIC > > > MEANING. It's a pure optimization that doesn't actually change > > > anything else. If you don't do the optimization, absolutely nothing > > > changes. > > > > And if the parser is well written the optimisation

Re: [PATCH 00/11] pragma once: treewide conversion

On Sat, Mar 6, 2021 at 5:07 AM Miguel Ojeda wrote: > > Concerning #pragma once: I actually would like to have a standard > #once directive if what is a "seen file" could be defined a bit more > precisely. I think it would be ok if you had something like #pragma onc

Re: [PATCH 00/11] pragma once: treewide conversion

a " character matches the last category, the behavior is undefined." in 6.4. Concerning #pragma once: I actually would like to have a standard #once directive if what is a "seen file" could be defined a bit more precisely. Even if just says it creates a guard with s

Re: [PATCH 00/11] pragma once: treewide conversion

On Fri, Mar 5, 2021 at 1:19 AM David Laight wrote: > > The point is that you can skip the unwanted parts of > #if without having to parse the file at all. > You just need to detect the line breaks. That's not actually true AT ALL. You still need to at the very least parse the preprocessor

RE: [PATCH 00/11] pragma once: treewide conversion

From: Linus Torvalds > Sent: 04 March 2021 20:16 > > On Thu, Mar 4, 2021 at 5:55 AM David Laight wrote: > > > > > (a) the traditional include guard optimization HAS NO HIDDEN SEMANTIC > > > MEANING. It's a pure optimization that doesn't actually change > > > anything else. If you don't do the

Re: [PATCH 00/11] pragma once: treewide conversion

was behind this macro test, so next time I see this file, if that macro is set, I can just ignore it". So it is actually a very important optimization. It's just that the optimization is better done with that explicit guard memoization than it is with '#pragma once' Linus

Re: [PATCH 10/11] pragma once: delete few backslashes

On 28/02/2021 17:05, Alexey Dobriyan wrote: > From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Fri, 19 Feb 2021 13:37:24 +0300 > Subject: [PATCH 10/11] pragma once: delete few backslashes > > Some macros contain one backslas

RE: [PATCH 00/11] pragma once: treewide conversion

> (a) the traditional include guard optimization HAS NO HIDDEN SEMANTIC > MEANING. It's a pure optimization that doesn't actually change > anything else. If you don't do the optimization, absolutely nothing > changes. And if the parser is well written the optimisation is probably irrelevant

Re: [PATCH 06/11] pragma once: convert include/linux/cb710.h

On Sun, Feb 28, 2021 at 08:02:10PM +0300, Alexey Dobriyan wrote: > From 1c4107e55b322dada46879837d4d64841bc5f150 Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Tue, 9 Feb 2021 16:56:54 +0300 > Subject: [PATCH 06/11] pragma once: convert include/linux/cb710.h &g

Re: [PATCH 00/11] pragma once: treewide conversion

so. That bugzilla is actually worth reading, if only to explain how the include guard is more robust technology compared to #pragma once. The traditional include guarding with #ifndef/#define/#endif around the contents has the advantage that a compiler _can_ generate the obvious trivial optimizations

Re: [PATCH 10/11] pragma once: delete few backslashes

On 2/28/21 9:05 AM, Alexey Dobriyan wrote: From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Fri, 19 Feb 2021 13:37:24 +0300 Subject: [PATCH 10/11] pragma once: delete few backslashes Some macros contain one backslash too many and end up being

Re: [PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types

b 2021 14:37:40 +0300 > > Subject: [PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types > > > > Generate arch/arm/include/generated/asm/mach-types.h without include > > guard. > > The fundamental question of "why" is missing from this commit message. &

Re: #pragma once (was Re: incoming)

s 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 on

Re: [PATCH 12/11] pragma once: scripted treewide conversion

subsystem] > [ Please see [PATCH 11/11: pragma once: conversion script (in Python 2)] ] > > Hi, Linus. > > Please run the script below from top-level directory, it will convert > most kernel headers to #pragma once directive advancing them into > 21-st century. > >

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&quo

Re: [PATCH 04/11] pragma once: convert drivers/gpu/drm/pl111/pl111_nomadik.h

On Sun, Feb 28, 2021 at 6:00 PM Alexey Dobriyan wrote: > From fe8504a1a0b5352cbc676b933c3dbb79ae9f59c9 Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Tue, 9 Feb 2021 16:50:24 +0300 > Subject: [PATCH 04/11] pragma once: convert > drivers/gpu/drm/pl111/pl111_nomadik.h &g

Re: [PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types

On Sun, Feb 28, 2021 at 07:59:16PM +0300, Alexey Dobriyan wrote: > From 72842f89ae91a4d02ea29604f87c373052bd3f64 Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Tue, 9 Feb 2021 14:37:40 +0300 > Subject: [PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types >

Re: [PATCH 10/11] pragma once: delete few backslashes

On Sun, Feb 28, 2021 at 08:05:14PM +0300, Alexey Dobriyan wrote: > From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Fri, 19 Feb 2021 13:37:24 +0300 > Subject: [PATCH 10/11] pragma once: delete few backslashes > > Some

Re: [PATCH 08/11] pragma once: convert scripts/atomic/

On Sun, Feb 28, 2021 at 08:03:18PM +0300, Alexey Dobriyan wrote: > From f10fe79897fa9600f144c76bc5df52dba28b7a66 Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Tue, 9 Feb 2021 01:37:55 +0300 > Subject: [PATCH 08/11] pragma once: convert scripts/atomic/ > > Gener

Re: [PATCH 00/11] pragma once: treewide conversion

On Sun, Feb 28, 2021 at 10:34:46PM +0300, Alexey Dobriyan wrote: > > gcc does > > open "/" + "whatever between quotes" > fstat > > so that "1.h" and "./1.h" differ When I try the following with GCC 10.2: $ c

Re: [PATCH 05/11] pragma once: convert drivers/scsi/qla2xxx/qla_target.h

gt; -#ifndef __QLA_TARGET_H > -#define __QLA_TARGET_H > - > +#pragma once > #include "qla_def.h" > #include "qla_dsd.h" Please insert a blank line between #pragma once and the #include directives. Thanks, Bart.

Re: [PATCH 00/11] pragma once: treewide conversion

gt; > kind of magical behavior. You continue to not even answer this very fundamental question. "#pragma once" doesn't seem to have a _single_ actual real advantage. Everybody already does the optimization of not even opening - much less reading and re-parsing - headers that have the

Re: [PATCH 00/11] pragma once: treewide conversion

On Sun, Feb 28, 2021 at 09:46:17AM -0800, Linus Torvalds wrote: > On Sun, Feb 28, 2021 at 8:57 AM Alexey Dobriyan wrote: > > > > This is bulk deletion of preprocessor include guards and conversion > > to #pragma once directive. > > So as mentioned earlier, I

Re: [PATCH 01/11] pragma once: delete include/linux/atm_suni.h

On Sun, 28 Feb 2021 19:58:17 +0300 Alexey Dobriyan wrote: > From c17ac63e1334c742686cd411736699c1d34d45a7 Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Wed, 10 Feb 2021 21:07:45 +0300 > Subject: [PATCH 01/11] pragma once: delete include/linux/atm_suni.h > > This f

Re: [PATCH 09/11] pragma once: convert scripts/selinux/genheaders/genheaders.c

0 > > Subject: [PATCH 09/11] pragma once: convert > > scripts/selinux/genheaders/genheaders.c > > > > Generate security/selinux/flask.h and security/selinux/av_permissions.h > > without include guards. > > > > Signed-off-by: Alexey Dobriyan > > --- >

Re: [PATCH 09/11] pragma once: convert scripts/selinux/genheaders/genheaders.c

On Sun, Feb 28, 2021 at 12:04 PM Alexey Dobriyan wrote: > > From 097f2c8b2af7d9e88cff59376ea0ad51b95341cb Mon Sep 17 00:00:00 2001 > From: Alexey Dobriyan > Date: Tue, 9 Feb 2021 00:39:23 +0300 > Subject: [PATCH 09/11] pragma once: convert > scripts/selinux/genheaders/genhead

Re: [PATCH 00/11] pragma once: treewide conversion

On Sun, Feb 28, 2021 at 8:57 AM Alexey Dobriyan wrote: > > This is bulk deletion of preprocessor include guards and conversion > to #pragma once directive. So as mentioned earlier, I'm not 100% convinced about the advantage of #pragma once. But I decided to actually test it, and it

[PATCH 12/11] pragma once: scripted treewide conversion

[ Bcc a lot of lists so that people understand what's this is all ] [ about without creating uber-cc-thread. ] [ Apologies if I missed your subsystem] [ Please see [PATCH 11/11: pragma once: conversion script

[PATCH 11/11] pragma once: conversion script (in Python 2)

>From 2bffcdfec69a8d28e9cb2c535724fbba8e12b820 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 14:47:34 +0300 Subject: [PATCH 11/11] pragma once: conversion script (in Python 2) Script accepts list of files to be converted from the command line, strips include guard if

[PATCH 10/11] pragma once: delete few backslashes

>From 251ca5673886b5bb0a42004944290b9d2b267a4a Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Fri, 19 Feb 2021 13:37:24 +0300 Subject: [PATCH 10/11] pragma once: delete few backslashes Some macros contain one backslash too many and end up being the last macro in a header file. When #pra

[PATCH 09/11] pragma once: convert scripts/selinux/genheaders/genheaders.c

>From 097f2c8b2af7d9e88cff59376ea0ad51b95341cb Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 00:39:23 +0300 Subject: [PATCH 09/11] pragma once: convert scripts/selinux/genheaders/genheaders.c Generate security/selinux/flask.h and security/selinux/av_permissions.h with

[PATCH 07/11] pragma once: convert kernel/time/timeconst.bc

>From e428633ff0df5fe8501aaf785c6961fc766344b2 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 00:31:23 +0300 Subject: [PATCH 07/11] pragma once: convert kernel/time/timeconst.bc Generate include/generated/timeconst.h without include guard. Signed-off-by: Alexey Dobri

[PATCH 08/11] pragma once: convert scripts/atomic/

>From f10fe79897fa9600f144c76bc5df52dba28b7a66 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 01:37:55 +0300 Subject: [PATCH 08/11] pragma once: convert scripts/atomic/ Generate atomic headers without include guards. Signed-off-by: Alexey Dobriyan --- include/asm-gene

[PATCH 06/11] pragma once: convert include/linux/cb710.h

>From 1c4107e55b322dada46879837d4d64841bc5f150 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 16:56:54 +0300 Subject: [PATCH 06/11] pragma once: convert include/linux/cb710.h This file is concatenation of two files with two include guards. Convert it manually. Signed-

[PATCH 04/11] pragma once: convert drivers/gpu/drm/pl111/pl111_nomadik.h

>From fe8504a1a0b5352cbc676b933c3dbb79ae9f59c9 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 16:50:24 +0300 Subject: [PATCH 04/11] pragma once: convert drivers/gpu/drm/pl111/pl111_nomadik.h This file has broken include guard, convert it manually. Signed-off-by: Ale

[PATCH 05/11] pragma once: convert drivers/scsi/qla2xxx/qla_target.h

>From 1f58b4923ca9bfb8b1e73554d3793ee98ab58a77 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 17:14:25 +0300 Subject: [PATCH 05/11] pragma once: convert drivers/scsi/qla2xxx/qla_target.h This file has broken include guard which is not obvious just by looking at the c

[PATCH 03/11] pragma once: convert arch/s390/tools/gen_facilities.c

>From 45622ce1e4db512ad603dd90f959e61285b7541a Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 14:43:52 +0300 Subject: [PATCH 03/11] pragma once: convert arch/s390/tools/gen_facilities.c Generate arch/s390/include/generated/asm/facility-defs.h without include guard. Sig

[PATCH 01/11] pragma once: delete include/linux/atm_suni.h

>From c17ac63e1334c742686cd411736699c1d34d45a7 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Wed, 10 Feb 2021 21:07:45 +0300 Subject: [PATCH 01/11] pragma once: delete include/linux/atm_suni.h This file has been empty since 2.3.99-pre3! Delete it instead of converting to #pragma o

[PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types

>From 72842f89ae91a4d02ea29604f87c373052bd3f64 Mon Sep 17 00:00:00 2001 From: Alexey Dobriyan Date: Tue, 9 Feb 2021 14:37:40 +0300 Subject: [PATCH 02/11] pragma once: convert arch/arm/tools/gen-mach-types Generate arch/arm/include/generated/asm/mach-types.h without include guard. Signed-

[PATCH 00/11] pragma once: treewide conversion

This is bulk deletion of preprocessor include guards and conversion to #pragma once directive. See [PATCH 11/11] and [PATCH 12/11] for the script and rationale. Everything else is trivial stuff.

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 effective

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 th

#pragma once (was Re: incoming)

Linus wrote: > I'm hoping to just do -rc1 this weekend after all - despite my late > start due to loss of power for several days. > > I'll allow late stragglers with good reason through, but the fewer of > those there are, the better, of course. I want to sent treewide "#pra

Re: [PATCH] proc: use #pragma once

On Fri, May 04, 2018 at 01:23:12AM +0200, Rasmus Villemoes wrote: > > Note that sequence of preprocessor tokens does not depend upon the ifdefs; > > anything under #if 0 *is* tokenized all the same. So it's not even that > > "parsing" (tokenizing, actually) has to be repeated. > > Are you sure

Re: [PATCH] proc: use #pragma once

On Fri, May 04, 2018 at 01:23:12AM +0200, Rasmus Villemoes wrote: > > Note that sequence of preprocessor tokens does not depend upon the ifdefs; > > anything under #if 0 *is* tokenized all the same. So it's not even that > > "parsing" (tokenizing, actually) has to be repeated. > > Are you sure

Re: [PATCH] proc: use #pragma once

al >> flag for mm.h, so it goes slurping in mm.h again. Obviously, the >> definedness of _LINUX_MM_H at that point means it "only" has to parse >> those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With >> #pragma once, the flag gets set for mm.h im

Re: [PATCH] proc: use #pragma once

al >> flag for mm.h, so it goes slurping in mm.h again. Obviously, the >> definedness of _LINUX_MM_H at that point means it "only" has to parse >> those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With >> #pragma once, the flag gets set for mm.h im

Re: [PATCH] proc: use #pragma once

bviously, the > definedness of _LINUX_MM_H at that point means it "only" has to parse > those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With > #pragma once, the flag gets set for mm.h immediately, so the #include > from memremap.h is entirely ignored. This can easily be

Re: [PATCH] proc: use #pragma once

bviously, the > definedness of _LINUX_MM_H at that point means it "only" has to parse > those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With > #pragma once, the flag gets set for mm.h immediately, so the #include > from memremap.h is entirely ignored. This can easily be

Re: [PATCH] proc: use #pragma once

ag for mm.h, so it goes slurping in mm.h again. Obviously, the definedness of _LINUX_MM_H at that point means it "only" has to parse those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With #pragma once, the flag gets set for mm.h immediately, so the #include from memremap.h is

Re: [PATCH] proc: use #pragma once

slurping in mm.h again. Obviously, the definedness of _LINUX_MM_H at that point means it "only" has to parse those 87K for comments and matching up #ifs, #ifdefs,#endifs etc. With #pragma once, the flag gets set for mm.h immediately, so the #include from memremap.h is entirely ignored. This can ea

Re: [PATCH] proc: use #pragma once

On Thu, 26 Apr 2018 22:24:44 +0300 Alexey Dobriyan wrote: > > The LOC argument also does not sound very convincing. > > When was the last time you did -80 kLOC patch for free? That would be the way to do it - sell the idea to Linus, send him a script to do it then stand

Re: [PATCH] proc: use #pragma once

On Thu, 26 Apr 2018 22:24:44 +0300 Alexey Dobriyan wrote: > > The LOC argument also does not sound very convincing. > > When was the last time you did -80 kLOC patch for free? That would be the way to do it - sell the idea to Linus, send him a script to do it then stand back. The piecemeal

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 03:33:04AM -0700, Christoph Hellwig wrote: > On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > > There are about 20k header files, none of them has #pragma once. > > Updating that will bring many unnesessry git commits. > > > > I

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 03:33:04AM -0700, Christoph Hellwig wrote: > On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > > There are about 20k header files, none of them has #pragma once. > > Updating that will bring many unnesessry git commits. > > > > I

Re: [PATCH] proc: use #pragma once

gt; > > > Bring /proc into 21st century. > > > > > > Please explain what this actually buys us except for being pointlessly > > > different from the rest of the kernel? > > > > Negative LOC diff, less junk in preprocessor hashtables. > >

Re: [PATCH] proc: use #pragma once

gt; > > > Bring /proc into 21st century. > > > > > > Please explain what this actually buys us except for being pointlessly > > > different from the rest of the kernel? > > > > Negative LOC diff, less junk in preprocessor hashtables. > >

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > There are about 20k header files, none of them has #pragma once. > Updating that will bring many unnesessry git commits. > > I doubt that one more define in preprocessor tables is a problem we > should fix. The LOC arg

Re: [PATCH] proc: use #pragma once

On Thu, Apr 26, 2018 at 12:26:29PM +0200, David Sterba wrote: > There are about 20k header files, none of them has #pragma once. > Updating that will bring many unnesessry git commits. > > I doubt that one more define in preprocessor tables is a problem we > should fix. The LOC arg

Re: [PATCH] proc: use #pragma once

t this actually buys us except for being pointlessly > > different from the rest of the kernel? > > Negative LOC diff, less junk in preprocessor hashtables. There are about 20k header files, none of them has #pragma once. Updating that will bring many unnesessry git commits. I doubt t

Re: [PATCH] proc: use #pragma once

t this actually buys us except for being pointlessly > > different from the rest of the kernel? > > Negative LOC diff, less junk in preprocessor hashtables. There are about 20k header files, none of them has #pragma once. Updating that will bring many unnesessry git commits. I doubt t

#pragma once

without "#pragma once" support. Script modifies files in place and gives up if something goes wrong even slightly. Use "#pragma once" in you code today! #!/usr/bin/python2 # Change include guard to "#pragma once" directive in place. import os import re impo

#pragma once

without "#pragma once" support. Script modifies files in place and gives up if something goes wrong even slightly. Use "#pragma once" in you code today! #!/usr/bin/python2 # Change include guard to "#pragma once" directive in place. import os import re impo

Re: [PATCH] proc: use #pragma once

On Tue, Apr 24, 2018 at 06:54:09AM -0700, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 12:35:34AM +0300, Alexey Dobriyan wrote: > > Bring /proc into 21st century. > > Please explain what this actually buys us except for being pointlessly > different from the rest of the kernel? Negative

Re: [PATCH] proc: use #pragma once

On Tue, Apr 24, 2018 at 06:54:09AM -0700, Christoph Hellwig wrote: > On Tue, Apr 24, 2018 at 12:35:34AM +0300, Alexey Dobriyan wrote: > > Bring /proc into 21st century. > > Please explain what this actually buys us except for being pointlessly > different from the rest of the kernel? Negative

Re: [PATCH] proc: use #pragma once

On Tue, Apr 24, 2018 at 12:35:34AM +0300, Alexey Dobriyan wrote: > Bring /proc into 21st century. Please explain what this actually buys us except for being pointlessly different from the rest of the kernel?

Re: [PATCH] proc: use #pragma once

On Tue, Apr 24, 2018 at 12:35:34AM +0300, Alexey Dobriyan wrote: > Bring /proc into 21st century. Please explain what this actually buys us except for being pointlessly different from the rest of the kernel?

[PATCH] proc: use #pragma once

c/fd.h @@ -1,7 +1,5 @@ /* SPDX-License-Identifier: GPL-2.0 */ -#ifndef __PROCFS_FD_H__ -#define __PROCFS_FD_H__ - +#pragma once #include extern const struct file_operations proc_fd_operations; @@ -16,5 +14,3 @@ static inline unsigned int proc_fd(struct inode *inode) { return PROC_I(inod

[PATCH] proc: use #pragma once

-License-Identifier: GPL-2.0 */ -#ifndef __PROCFS_FD_H__ -#define __PROCFS_FD_H__ - +#pragma once #include extern const struct file_operations proc_fd_operations; @@ -16,5 +14,3 @@ static inline unsigned int proc_fd(struct inode *inode) { return PROC_I(inode)->fd; } - -#en

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, >

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 > su

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

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

Re: #pragma once?

ues.] > >> > >> 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 > >>

Re: #pragma once?

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

Re: #pragma once?

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

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&

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

Re: #pragma once?

__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

Re: #pragma once?

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

Re: #pragma once?

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

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 includ

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 includ

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

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? > > S

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

#pragma once?

[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 add

#pragma once?

[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

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

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

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

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

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