Re: [PATCH] Use __unused0 instead of __unused for user visible struct members

["Carlos O'Donell" <carlos at systemhalted dot org>]

On Sun, Jan 29, 2012 at 12:06 PM, Ulrich Drepper <drepper@gmail.com> wrote:
> On Sun, Jan 29, 2012 at 11:14, Carlos O'Donell <carlos@systemhalted.org> wrote:
>> I still see no clear technical reason not to apply a patch which has
>> immediate benefit to the community.
>
> There is no benefit. ?It just means that people continue to write
> broken code and will continue demanding that correct code is changed.
> Fix that code.

There is value in supporting an existing body of code.
=========================================

It's not like this is a new thing that's being attempted, but instead
it represents an existing body of code. There is value in supporting
that existing body of code. There is a direct benefit to the glibc
community by enabling the building of more application code.

There is no technical reason to reject the suggested changes.
===============================================

There is no technical reason to reject the suggested changes, no
runtime performance penalty, and no additional code to maintain. Given
the length of this conversation we are not likely to forget the
convention of using __unused0.

In summary
=========

(1) Mechanical change to enable the compiling of an existing body of
code, even if it is not 100% conforming.

(2) Ask the glibc community (which just submitted the patch) to make a
large mechanical change across a large code base to comply with the
standard.

I argue that choice (2) conflates the issue of standards conformance
checking and the project goals of providing a portable C library.

Even though choice (2) is where we want to be in the long run I don't
believe that ignoring the community is an effective way to achieve
standards compliance, nor does it address higher priority standards
compliance issues (like automatically detecting the use of __ prefixed
names and issuing diagnostic messages) and therefore is of low value
compared to the benefit of compiling more user code with glibc.

Therefore I argue choice (1) is inherently better, supports the
community, and has no detrimental impact on the project.

Cheers,
Carlos.