linux-kernel - Re: #pragma once (was Re: incoming)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YDl9/QU8EsCOPyuf@localhost.localdomain>
Date:   Sat, 27 Feb 2021 02:02:21 +0300
From:   Alexey Dobriyan <adobriyan@...il.com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: 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 <adobriyan@...il.com> 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.