strtod_l is defined in xlocale.h.
This fixes:
parser.y:287:19: error: implicit declaration of function 'strtod_l' is invalid in C99 [-Werror,-Wimplicit-function-declaration] double result = strtod_l(s, &remain, locale);
on FreeBSD
Lint Skipped |
Unit Tests Skipped |
Note that at least glibc defines strtod_l in stdlib.h, I think it's safer to include both stdlib.h for glibc and xlocale.h for OSX and the BSDs.
We had some problems here on OSX... Adding Stefan to review this change, too. Stefan, can you please verify the OSX build with this?
strtod_l needs stdlib.h and xlocale.h on BSD. But we also need locale.h for newlocale().
If one has to trust http://illumos.org/man/3head/xlocale.h it says
As none of the definitions supplied in this header, nor this header
itself, are specified in any standard, their use should be avoided in
portable applications.
So are we really sure we want it?
https://www.freebsd.org/cgi/man.cgi?query=xlocale&sektion=3 :
CONVENIENCE FUNCTIONS The xlocale API includes a number of _l suffixed convenience functions. These are variants of standard C functions that have been modified to take an explicit locale_t parameter as the final argument or, in the case of variadic functions, as an additional argument directly before the for- mat string. Each of these functions accepts either NULL or LC_GLOBAL_LOCALE. In these functions, NULL refers to the C locale, rather than the thread's current locale. If you wish to use the thread's current locale, then use the unsuffixed version of the function. These functions are exposed by including <xlocale.h> after including the relevant headers for the standard variant. For example, the strtol_l(3) function is exposed by including <xlocale.h> after <stdlib.h>, which defines strtol(3).
This has been fixed in the meantime in 57d50355fe02dbfef69fb58ccab2267f133df6eb and 4ff0c7505c7c4903a3dc627baafe98f987796f0c