Eric Blake <e...@byu.net> writes: > Simon Josefsson <simon <at> josefsson.org> writes: > >> >> My patch didn't illustrate my point correctly: my point was that, >> according to Bruno (and my checks), we do know that at least Mac OS X >> 10.5 implements the *_l functions, so arguable our documentation should >> say that. > > I still think that's overkill. Remember, the docs exist to show that there > are > known non-compliances with POSIX 2008, and what gnulib does about that. We > don't have to list all the bugs, just enough of a sampling that a package > maintainer can consider using the gnulib module to work around those flaws. > In > other words, listing known negative cases is important.
Good point. > But the list of platforms that implement POSIX 2008 will slowly grow over > time, > and as it does, we don't want to have to update the docs to list new positive > cases. What happens when cygwin 1.7.2 (or whatever future version) > implements > locale_t and the *_l functions? Do we have to sweep through the docs yet > again? So, keeping the docs in their current state, of listing only negative > cases, seems okay to me. The problem with this approach is that people will have only negative information to decide when it would make sense to use a gnulib-replacement module for a function, to deal with the platform that doesn't yet implement it. Personally, I think that if glibc, Mac OS X, cygwin and maybe Solaris supported some interface I may want to start rely on it as a maintainer, if I can get a replacement function into gnulib. But if only glibc supports an API, and there is no strong compelling reason to use it, I may prefer to use POSIX interfaces instead. /Simon
