Re: sort --version-sort

[Jim Meyering]

Eric Blake <address@hidden> wrote:
> Jim Meyering <jim <at> meyering.net> writes:
>
>> 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.
>
> No.  strcasecmp is specified by POSIX, in <strings.h>.  But strcasestr is pure
> extension, in <string.h>.

I reversed the names, but you got the point.  The intent (at least mine,
from day one) has been to put only standards-specified declarations
and definitions in gnulib-supplied header files like <string.h>.
Doing otherwise limits the general usability of a stand-alone .c/.h
pair like the one for strverscmp.  With the current separate .h file,
an application that uses the function and includes "strverscmp.h"
works just as well with as without gnulib's replacement <string.h>.
However, if we were to move the declaration into <string.h>, that would
tie applications to the gnulib-generated <string.h>.  That feels like
a move in the wrong direction.

In addition since strverscmp is an LC_COLLATE-ignoring string comparison
function, it seems unwise to ensconce it in gnulib's string.h.

> Also, Bruno added all his mbs* functions in gnulib's <string.h>...

His decision.  Since those mbs* functions already have so many gnulib-
related dependencies, adding the dependency on gnulib's generated
<string.h> doesn't limit their usability.

>> 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.
>
> ...so it looks like Bruno would want to get his mbs* stuff standardized at the
> same time.  At any rate, based on the number of GNU functions standardized in
> 200x (such as strdup), we stand a chance of being able to pull off additional
> functions in the next POSIX revision however many years down the road.

All that said, since strverscmp is already in Linux's <string.h>
(albeit behind _GNU_SOURCE), I won't object if you want to go
ahead with this.