bug#7213: [PATCH] sort: fix buffer overrun on 32-bit hosts when warning re obsolete keys

[Jim Meyering]

Paul Eggert wrote:
> On 10/14/10 03:27, Pádraig Brady wrote:
>> So the test failed due to buffer overrun side effects?
>
> I think so, yes, though I didn't investigate the details.
>
> On 10/14/10 02:37, Jim Meyering wrote:
>> With the following patch, compilation now fails on x86-based systems:
>>
>> sort.c: In function 'key_warnings':
>> sort.c:2335: error: negative width in bit-field 
>> 'verify_error_if_negative_size__'
>> sort.c:2335: error: negative width in bit-field 
>> 'verify_error_if_negative_size__'
> ...
>
> I assume this is against the unpatched sort.c.  It's nice that

Right.

> it generates a diagnostic, but why is it generating duplicate
> diagnostics for each error?

That surprised me, too.
umaxtostr is used there as an argument to stpcpy,

          po = stpcpy (stpcpy (po, "+"), umaxtostr (sword, tmp));

and stpcpy happens to be a macro on glibc-based systems.

>> BTW, for fyi-style patches like this,
>> please use address@hidden rather than bug-...
>
> Sorry about posting to bug-coreutils; I forgot that I was
> supposed to send it to coreutils.  But even if I had remembered,
> I thought I was supposed to send patches to coreutils only if I
> had applied them, under the theory that the bug had already been
> fixed.  So the real rule is: send patches to coreutils, and
> bug reports without patches to bug-coreutils?

Actually, you're welcome to send them to either,
but if you send them to bug-coreutils, please close
the ticket once your patch has been pushed.