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] [day] [month] [year] [list]

Message-ID: <YD1OjvWcal+rPz+4@zeniv-ca.linux.org.uk>
Date:   Mon, 1 Mar 2021 20:29:02 +0000
From:   Al Viro <viro@...iv.linux.org.uk>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: 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...