Re: ISO C11 issues for glibc

[Roland McGrath <roland at hack dot frob dot com>]

> Without that header, __STDC_NO_ATOMICS__ should be predefined - and 
> without threads.h, __STDC_NO_THREADS__ should be predefined (properly of 
> course before the source file includes any headers, and in a way that 
> allows a separate implementation of the features to cause the macros to be 
> predefined, but the best you can do at present given the rejection of my 
> patches for bug 10110 is defining these macros in features.h).  Given the 
> need for predefined macros if you don't support those features, I suppose 
> there's a case for a bug at least to say that those macros should be 
> defined.

If we stick with the preference Ulrich expressed in bug 10110 then all the
predefine issues require more coordination with GCC.  But for practical
usability leaving aside pedantic ISO requirements, applications can include
something generic and harmless like <stdio.h> or <limits.h> before testing
these things.  So I think the first step is to make the libc headers work
right for that case.  Then we can revisit the question of the coordination
with GCC.

As for __STDC_NO_THREADS__, I've only glanced at (the draft I could find
of) the spec.  But it looks like implementing those as a layer on top of
pthreads would be quite straightforward.  (Off hand, I think it makes sense
to put that in a static-only -lthrd that causes a link-time dependency on
libpthread.  i.e., libthrd.{a,so} would be a linker script doing:
INPUT ( libthrd_nonshared.a libpthread.a )
and:
INPUT ( libthrd_nonshared.a libpthread.so )
respectively.)  To avoid extra indirection and allocation in the ISO C
threads data types, we'd need to get the bits/pthreadtypes.h information
into a form usable by the new ISO C header without name space pollution.
Having bits/pthreadtypes.h define __pthread_*t names and putting a set
of "typedef __pthread_foo_t pthread_foo_t;" definitions into pthread.h
seems like the right thing to me.

Given how simple it looks to support the ISO C threads interfaces as
wrappers, it seems worthwhile to just do that now rather than bother with
an immediate __STDC_NO_THREADS__ change and leave the wrappers for later.
But perhaps there is some complexity or drawback I've overlooked (I've
really only glanced at the new spec, and only at an older draft).

What do you think?


Thanks,
Roland