Re: __thread

[Fergus Henderson <fjh at cs dot mu dot OZ dot AU>]

On 20-Mar-2003, Jonathan Larmour <jifl at eCosCentric dot com> wrote:
> >On 14-Mar-2003, Tam?s Gergely <gertom at rgai dot hu> wrote:
> >>In file included from ../include/pthread.h:1,
> >>                 from ../linuxthreads/sysdeps/pthread/bits/libc-lock.h:23,
> >>                 from ../sysdeps/generic/ldsodefs.h:34,
> >>                 from ../sysdeps/unix/sysv/linux/ldsodefs.h:25,
> >>                 from ../sysdeps/unix/sysv/linux/init-first.c:32:
> >>../linuxthreads/sysdeps/pthread/pthread.h:163: error: parse error before 
> >>"__thread"
> >
> >Ouch.  According to the C standard, the section of the namespace
> >starting with "__" is reserved for use by the implementation, but the
> >implementation consists of two parts, a compiler and a library,
> >and in this case there is a name clash -- GCC's use of "__thread"
> >clashes with glibc's use of it.
> 
> This could easily have been foreseen. eCos has been bitten by this too, as 
> well as no doubt many other OS's, kernels and runtime systems (although 
> most don't know it yet). We can fix what we've got now, but now we'll be 
> annoyed by people who can't get older (than today) versions of the sources 
> to compile with newer GCC.
> 
> It's pretty obvious that this type of identifier would relate closely to 
> the operation of an OS and would be likely to appear there, and GCC should 
> not just assume that it can use any old identifier just because it sticks 
> "__" in front of it, and it's up to everyone else to deal with it.
> 
> May I suggest that GCC extensions be labelled as such, e.g. __gcc_thread ? 
> Then there's a hope of avoiding clashes between OS's and compilers. That 
> would seem the most professional approach.

When GCC adds new identifiers to the implementation namespace, these
symbols are usually intended for use by users.  For example, they may be
new keywords or new built-in functions.  In contrast, identifiers in the
implementation namespace which are defined by the OS or C library are
usually intended only for internal use by the OS or C library, not for
use by users -- otherwise they should be given a non-"__"-prefixed name.
There are some exceptions to this (e.g. _POSIX_C_SOURCE and similar),
but it does seem to be the general rule.

Using a longer prefix such as "__gcc_" rather than "__" is probably
undesirable in names intended for use by users.  Given this, wouldn't
it make more sense for the OS and C library to use such prefixes, rather
than GCC?

-- 
Fergus Henderson <fjh at cs dot mu dot oz dot au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.