Re: __thread

[Jonathan Larmour <jifl at eCosCentric dot com>]

> 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.

Jifl
--
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--[ "You can complain because roses have thorns, or you ]--
--[  can rejoice because thorns have roses." -Lincoln   ]-- Opinions==mine