Re: sort --version-sort

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>> > Would you rather I submit a simple patch to coreutils that adds
>> > #include "strverscmp.h" to sort.c, or a more complete patch to gnulib that
>> > guarantees a declaration of strverscmp in the gnulib replacement <string.h>
> to
>> > match Linux?
>>
>> What service
>>
>> I think we'll have to include "strverscmp.h",
>> since portable applications should be expecting a
                                     ^not
>> strverscmp declaration in string.h.
>
> Missing a "not" somewhere in there.

Right.  Thanks.

> But I disagree about what a portable app
> should expect - the point of gnulib replacement headers is that we guarantee
> that <string.h> will portably declare strverscmp.  For comparison, look at how
> we rely on the gnulib headers for other GNU extensions such as strcasestr.

I wondered if there were any GNU-specific functions, and even searched
for *GNU* macros that might guard their declarations in string.in.h.
There are none.  The main difference is that strcasestr is specified by
POSIX and a declaration in string.h is required, while strverscmp is not.

I think it would be a mistake to encourage gnulib application writers
to rely on <string.h> declaring the nonstandard strverscmp function.

However, if you can convince the open group to add it for POSIX-201x,
it'd make perfect sense to add it to gnulib's string.in.h now.

> Besides, fixing it in gnulib will benefit any other package developed 
> primarily
> on Linux but which forgets to include "strverscmp.h". So I'm going ahead with
> a gnulib patch... oh, and I guess that means I'm also volunteering to write a
> gnulib unit test for strverscmp...

Test suite additions are always welcome ;-)