This is the mail archive of the
mailing list for the glibc project.
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 <firstname.lastname@example.org> 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
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
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
<http://sourceware.org/ml/libc-alpha/2011-08/msg00084.html>) 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