linux-kernel - Re: [PATCH] proc: use #pragma once

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]

Date:   Thu, 3 May 2018 23:42:57 +0100
From:   Al Viro <viro@...IV.linux.org.uk>
To:     Rasmus Villemoes <linux@...musvillemoes.dk>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Alexey Dobriyan <adobriyan@...il.com>, dsterba@...e.cz,
        Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] proc: use #pragma once

On Fri, May 04, 2018 at 12:14:57AM +0200, Rasmus Villemoes wrote:

> FWIW, it's not just removing some identifiers from cpp's hash tables, it
> also reduces I/O: Due to our header mess, we have some cyclic includes,
> e.g mm.h -> memremap.h -> mm.h. While parsing mm.h, cpp sees the #define
> _LINUX_MM_H, then goes parsing memremap.h, but since it hasn't reached
> the end of mm.h yet (seeing that there's nothing but comments outside
> the #ifndef/#endif pair), it hasn't had a chance to set the internal
> 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 immediately, so the #include
> from memremap.h is entirely ignored. This can easily be verified with
> strace. And mm.h is not the only header getting read twice.

Which gcc version it is?  Does it *really* read anything twice?  After all,
you are going to read (and tokenize) the rest of mm.h anyway, so if it
throws away the file it has read, only to reread it again, it's bloody
dumb.

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.