This is the mail archive of the libc-alpha@sourceware.org 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 struct members


On Mon, Jan 9, 2012 at 5:01 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Mon, Jan 9, 2012 at 16:53, Carlos O'Donell <carlos@systemhalted.org> wrote:
>> Is the key reason for not making the change because there may be
>> requests from others to make similar changes? That doesn't seem like
>> sound technical decision making. Each request would surely be
>> evaluated on its own merit.
>
> That's not possible. ?Everyone will claim their request is just as
> important as the others.

People can claim whatever they want, the decision still rests with the
project maintainers, and it should be their responsibility to judge the
merit of the request.

> These are no save names to use. ?Only the fact that for decades the _
> name space is reserved helps. ?If BSD think they can do what they want
> just don't use their code. ?Have them fix their code and not introduce
> into general namespaces. ?Guess why glibc uses lengthy names like
> __attribute_malloc__? ?Certainly not because it's convenient.

I agree that glibc is well written, and that well written code has a cost.

I also agree that the _ name space is reserved, it's clearly part of the
standard.

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?

Cheers,
Carlos.


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