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