This is the mail archive of the 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: [PATCH] Use __unused0 instead of __unused for user visible structmembers

On Sun, 29 Jan 2012, Carlos O'Donell wrote:

> On Mon, Jan 9, 2012 at 5:45 PM, Carlos O'Donell <> wrote:
> > Should a mechanical change, with no maintenance impact, be carried
> > out to enable the building of BSD code which is known to be
> > non-conforming, for the benefit of the user community that wishes
> > to use this code with glibc?
> >
> > Does the benefit to the community factor into the decision making?
> I still see no clear technical reason not to apply a patch which has
> immediate benefit to the community.
> Is there something I am missing regarding the other side of the argument?

I would add: a "slippery slope" argument was made earlier in this 
discussion, but in practice cases like this are very rare.  The only 
previous ones I recall were __vector and __block.  (Rather longer ago, 
__thread was used as a parameter name before TLS support was added - so 
requiring GCC to have fixincludes for existing headers after adding the 
__thread keyword.)

The basic issue is that standards are written in terms of a monolithic 
"the implementation" that combines compilers and libraries, and 
identifiers are reserved to that "the implementation".  But in practice 
the implementation is more fuzzily defined; it includes both GCC and 
glibc, which can cause problems if both try to use the same identifier 
(see __vector and AltiVec), and the installed headers may also be used 
with other compilers with their own reserved identifiers (see __block).  
And BSDs use a somewhat larger "the implementation" with closer 
integration between the kernel, libc and the rest of userspace - which is 
where the problem is coming from here, __unused being a standard BSD 
system API.

Ideally such conflicts would be avoided by each part of the implementation 
voluntarily using a unique prefix on its reserved identifiers; glibc might 
use __glibc_*, for example.  But given how rarely conflicts come up in 
practice, the full change to a glibc-specific namespace is probably 

I think we can decide these issues on a case-by-case basis.  glibc 
certainly does sometimes adapt to non-standard code - for example, the 
choice to map x86_64 memcpy to memmove for old symbol versions, and only 
use the version that actually breaks for overlap with new symbol versions.  
In standard terms the programs using memcpy with overlapping objects were 
wrong all along, and any change to the library has some possibility of 
breaking existing binaries that relied on some aspect of library behavior 
that wasn't guaranteed.  In that case a pragmatic choice was made of 
letting previously built buggy code continue to work but forcing any newly 
built code to use memcpy correctly.  Or consider the case of powerpc32 
malloc alignment, discussed here in August, where the status quo is that 
to avoid breaking emacs (which doesn't check for an error return from 
malloc_set_state, so is in the wrong in terms of how it uses documented 
libc interfaces), other binaries such as GDB (as per 
<>) are left 
broken with AltiVec enabled instead.

True, those two cases were both based on a strong presumption against 
breaking existing binaries, while the present one is about making it 
easier to use certain source code.  But there is a common feature that it 
can be useful to support code that does formally incorrect things and we 
judge such cases individually.

Joseph S. Myers

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