Re: #pragma once usage

[Zack Weinberg <zackw@panix.com>]

On Fri, Feb 26, 2021 at 2:10 PM Adhemerval Zanella via Libc-alpha
<libc-alpha@sourceware.org> wrote:
> Reviewing the dlmopen shared patchset, it propose the use of '#pragma once' on
> some tests header instead of include guards. I don't see an impending reason to
> not use it, however I would like to check if there any issue I am not seeing.

The POSIX filesystem API does not offer any 100% reliable mechanism
for determining whether two pathnames refer to the same file, which
means an implementation of #pragma once cannot be 100% reliable,
either.  GCC's implementation is probably as good as it can get, but
it can still make the wrong decision about whether two #include
directives refer to the same file under plausible conditions (e.g.
source on a network file system, client and server don't agree on the
current time). glibc builds use a very long list of -I switches, and
files at one point in the search path may #include files that appear
at a different point in the search path, and don't always consistently
use the same short name to do so; these factors make it more likely
that we'd actually be affected by the bugs.

My recommendation is that #pragma once should not be used anywhere in
glibc's source code.

> Besides being non standard features, it also does not really fit our requirement
> for exported headers, which usually add other headers and these check the include
> guards from 'parent' to emit an error if the these internal headers are included
> directly.

Semi-unrelated, but I think _all_ our headers should have their own
#ifdef guard, except for the few that are intended to be reread if
included a second time (e.g. bits/libc-header-start.h), which should
instead have a comment saying that they're special.

zw