[PATCH 1/3] platform: fix missing strchrnul

[Rich Felker]

On Wed, Nov 27, 2013 at 10:13:37PM +0100, Matthias Andree wrote:
> Am 27.11.2013 12:14, schrieb Daniel Borca:
> > 
> > 
> > Matthias Andree wrote:
> >>
> >> The whole #ifdef approach is massively broken and prone to mis-guess.
> >>
> >> It denies one of the most basic considerations, and that is: operating
> >> systems change over time, and add features missing from earlier
> >> versions.  Looking at the operating system is insufficient.
> >>
> >> [snip]
> >>
> >> Note I am not saying you need to use a fully-fledged autoconf approach,
> >> lighter-weight alternatives have been seen in the wild, and possibly it
> >> suffices - for FreeBSD - to have a separate header (.h) file that checks
> >> the major FreeBSD version and #defines a few HAVE_SOMEFUNCTION or leaves
> >> it #undef'd, so the actual code can then
> > 
> > That just means the cpp dancing is moved elsewhere.  Someone needs to
> > maintain that header, because OSes <quote> change over time </quote>.
> 
> The point is to autodetect, somehow, what the OS features and what it is
> missing, and go with that.
> 
> >> on his hands, so some concept similar to autoconf might work in more
> >> places with less human work and more machine work during the build.
> > 
> > I agree, autoconf is the best approach.  But *someone* needs to write
> > it.
> 
> I have not claimed autoconf to be the best approach, nor would I.
> 
> I am not writing such an autoconfiguration feature either, merely
> restating the recurring finding that guessing symbols from OS predefined
> macros is doomed.

For simply detecting the availability of optional/extension functions,
autoconf is not needed; such detection could easily be implemented
directly in the Makefile, with make rules which generate a header with
the HAVE_* macros defined based on the results of tests. However, a
lot of programs get these sorts of tests wrong even in autoconf. I've
written about this on my blog here:

http://ewontfix.com/13/

including details on how to write a correct test.

Rich