This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: What does it mean to include pthread.h with -std=c11?


On Fri, Dec 20, 2019 at 3:08 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> * Carlos O'Donell:
>
> > I'm on the fence here because it _used_ to work, and so it seems like at
> > some point we might have gone from (1) -> (2) without a deeper discussion
> > about exactly what kind of behaviour and maintenance responsibility we want
> > for these headers.
> >
> > Thoughts?
>
> We have a test for this, see scripts/check-installed-headers.sh.  It
> just fails to catch cases such as this because it cannot test that all
> the defined macros can be expanded.
>
> I think there are no two sides here.  #include <pthread.h> must work
> in ISO C mode.  Everything else is just very wrong.

I tend to agree, but we need a definition of "work".

I've always assumed that the intention was something like: if you
request strict conformance and then include a header that was added to
ISO C and/or POSIX at a conformance level above the one you picked,
you get the set of definitions that that header had as of the oldest
supported standard that included it.  (So, for instance, if you put
-std=c99 on the command line, don't define any _*_SOURCE macros, and
then include <threads.h>, you get what C11 specifies for that header,
and no more.)  This is what I had in mind when I wrote
check-installed-headers.sh.  I'm not aware of any cases where this
policy can't be made to work, but I haven't investigated it too
closely.

zw


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]