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-next>] [day] [month] [year] [list]
Date:	Mon, 6 Jan 2014 12:47:07 -0800
From:	Josh Triplett <josh@...htriplett.org>
To:	linux-kbuild@...r.kernel.org, linux-kernel@...r.kernel.org
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Michal Marek <mmarek@...e.cz>, Sam Ravnborg <sam@...nborg.org>,
	Rashika Kheria <rashika.kheria@...il.com>
Subject: #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 to Sparse myself.)  Both have equivalent performance.  "#pragma
once" is simpler, and avoids the possibility of a typo in the defined
guard symbol.

That's not a theoretical concern: I've found quite a few headers in the
kernel with typoed (and thus non-functional) include guards.  Rashika
Kheria (CCed) ran into one such header when attempting to add some
includes to fix some warnings (resulting in the broken header being
included twice), and that prompted me to look for other headers with
broken guards.  I've included a Python script at the end of this mail
that finds many such issues, though it does have a few false positives
on files that don't have include guards at all.

I'm not suggesting a mass conversion from include guards to "#pragma
once", though that *would* be fairly easy to script and review if
desired.  I'd just like to verify that "#pragma once" seems acceptable
before, for instance, converting the headers that already have broken
include guards, adding recommendations in Documentation to standardize
on the pragma for new headers, and possibly adding checks in checkpatch
or similar if I can come up with one that has minimal false positives.

Python script to check header guards (run with $(find -name '*.h') as
arguments, and grep for "mismatch" in the output if you don't care about
files without guards):

#!/usr/bin/python
import re
import sys

start = re.compile("[ \t]*#[ \t]*(ifndef|define)[ \t]+([a-zA-Z0-9_]*)")

def main(args):
    for header in args[1:]:
        symbol = None
        for line in open(header):
            m = start.match(line)
            if not m:
                if symbol:
                    print "{}: does not appear to use ifndef-based include guard".format(header)
                    break
                continue
            if m.group(1) == "ifndef":
                if symbol is not None:
                    print "{}: does not appear to use ifndef-based include guard".format(header)
                    break
                symbol = m.group(2)
            elif m.group(1) == "define":
                if symbol is None:
                    print "{}: does not appear to use ifndef-based include guard".format(header)
                    break
                if symbol != m.group(2):
                    print "{}: include guard symbol mismatch: #ifndef {} with #define {}".format(header, symbol, m.group(2))
                break
        else:
            if symbol:
                print "{}: ifndef {} with no subsequent define".format(header, symbol)

if __name__ == "__main__":
    sys.exit(main(sys.argv))
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ