Re: CVS commit: src/tools/compat

[Tom Spindler <dogcow%babymeat.com@localhost>]

On Mon, Oct 27, 2008 at 02:18:13PM +0000, Christos Zoulas wrote:
> In article <20081027050612.GB46068%babymeat.com@localhost>,
> Tom Spindler  <dogcow%babymeat.com@localhost> wrote:
> >> > Log Message:
> >> > Define __USE_ISOC99 for linux, making the isblank() proto appear.
> >> > This is probably not the Right Thing, but it seems to not break anything.
> >> 
> >> Yes, it is wrong. Can't you set define _GNU_SOURCE on Linux?
> >
> >You can, but that causes other things to break instead.
> >The actual correct thing would to be to fix the autoconf tests.
> 
> Like what? I think it is better to be compatible with _GNU_SOURCE in general
> rather than turning random defines on to expose certain functions.

config.log says:
configure:4993: checking for isblank
configure:5030: cc -o conftest -O   conftest.c -lz  >&5
configure:5009: warning: conflicting types for built-in function 'isblank'

which seems wrong; when you #define _GNU_SOURCE you instead get:
In file included from ./nbtool_config.h:625,
                 from 
/home/dogcow/work/nbsrc/tools/compat/../../lib/libc/stdlib/atoll.c:33:
/home/dogcow/work/nbsrc/tools/compat/compat_defs.h:373: error: expected 
identifier or '(' before '__extension__'

the preprocessed version of the code is

char *(__extension__ (__builtin_constant_p (const char *) && ((size_t)(const voi
d *)((const char *) + 1) - (size_t)(const void *)(const char *) == 1) ? (((__con
st char *) (const char *))[0] == '\0' ? (char *) calloc ((size_t) 1, (size_t) 1)
 : ({ size_t __len = strlen (const char *) + 1; size_t __n = (size_t); char *__r
etval; if (__n < __len) __len = __n + 1; __retval = (char *) malloc (__len); if
(__retval != ((void *)0)) { __retval[__len - 1] = '\0'; __retval = (char *) memc
py (__retval, const char *, __len - 1); } __retval; })) : __strndup (const char
*, size_t)));

presumably this occurs because configure isn't run with _GNU_SOURCE set,
and thus doesn't see strndup, and thus doesn't set HAVE_DECL_STRNDUP, 
which causes this fun to be spewed.

Of course, the _simplest_ thing for this entire mess would be to just
define and use a locally-defined (and simple-minded) isblank(), thus
avoiding the entire "is it a c9x symbol or not" issue.