Eric Blake <[EMAIL PROTECTED]> 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 ;-)
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
