public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
* #pragma once usage
@ 2021-02-26 19:10 Adhemerval Zanella
  2021-02-26 21:09 ` Zack Weinberg
  0 siblings, 1 reply; 2+ messages in thread
From: Adhemerval Zanella @ 2021-02-26 19:10 UTC (permalink / raw)
  To: GNU C Library, Vivek Das Mohapatra

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.

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.

However, I don't see why we can't start to use on glibc code itself (including
tests), at least to simplify some internal guards.  I haven't tested it, specially
on some headers that might be used on preprocessor mode to create constants by 
some scripts.

Is there any other issues that might prevent its internal usage?

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: #pragma once usage
  2021-02-26 19:10 #pragma once usage Adhemerval Zanella
@ 2021-02-26 21:09 ` Zack Weinberg
  0 siblings, 0 replies; 2+ messages in thread
From: Zack Weinberg @ 2021-02-26 21:09 UTC (permalink / raw)
  To: Adhemerval Zanella; +Cc: GNU C Library, Vivek Das Mohapatra

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2021-02-26 21:10 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-26 19:10 #pragma once usage Adhemerval Zanella
2021-02-26 21:09 ` Zack Weinberg

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).