Re: enable -Werror for lib/ in coreutils

[Jim Meyering]

Paolo Bonzini wrote:
> On 10/29/2009 10:02 AM, Jim Meyering wrote:
>> IMHO it is a bug fix.
>> A semantically unsigned variable must never be decremented to -1.
>> I didn't try to see if it could induce misbehavior.
>
> No, it couldn't.  The problem is that the variable is semantically
> unsigned in gnulib because of the IMHO debatable change of __re_idx_t
> from int to size_t, but upstream it is part of the contract that
> passing a negative value is acceptable (and a nop).

IMHO, the legacy (glibc) interfaces are inferior,
from correctness and readability points of view.
Whether it is better to revert to those interfaces
for the sake of maintainability is debatable indeed...

Nearly everything is debatable ;-)

>> > >  Why use a signed type throughout rege*.[ch] when an unsigned one
>> > >  more accurately models the data and interfaces?
>> >
>> >  Because upstream uses a signed type, and I'm not sure we want to
>> >  deviate from there.  I'd use intptr_t or ptrdiff_t.
>>
>> We deviated years ago.
>
> Yes, and it's been a pain for whoever backported bugfixes.  It's
> already hard enough to adjust the patches for int->Idx; however we
> complicated our lives by having to worry about signed/unsigned
> differences.
>
> I know about the ABI limitations of glibc, and I'm not saying it was
> wrong for gnulib to switch from int to something wider.  However, if
> we want to share the code (unlike fts, regex is sufficiently stable,
> complex and fundamental that we do) changing from signed to unsigned
> was a bad idea.

As I said, this sort of change is out of scope.

If you are prepared to take responsibility for rege* in gnulib
with the goal of reverting such changes, please announce it in a
separate thread, and we'll see what (if anything) others have to say.

In making your case, it would be good to be able to itemize
the glibc bug fixes that have not yet been ported to gnulib,
and contrast that gain with the (theoretical?) loss of support for
strings of length >= 2GiB.