bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] xalloc: add xstrndup


From: Paul Eggert
Subject: Re: [Bug-gnulib] xalloc: add xstrndup
Date: 18 Aug 2003 14:20:08 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Bruno Haible <address@hidden> writes:

> You are right; the stuff still using HAVE_STRING_H is obsolete now that
> we require C89 support

OK, but the story's more complicated than that.  The idea was that we
require only freestanding C89, not hosted C89.  This is because our
suggestion to the few people still running pre-C89 hosts like SunOS
4.x is to install GCC first; but GCC is only a freestanding compiler.
Strictly speaking, if we assume only freestanding C89 we can assume
only <float.h>, <limits.h>, <stdarg.h>, and <stddef.h>.  (We can also
assume the C99 freestanding <stdbool.h> because we supply it.)

However, we don't really need to be strict about freestanding C89.  We
can assume the existence of <assert.h>, <ctype.h>, <errno.h>,
<math.h>, <setjmp.h>, <signal.h>, <stdio.h>, and <time.h>, as all
those headers were present in Unix Version 7.  (mkdtemp.c tests
for HAVE_TIME_H, but I doubt whether this is really needed.)

<string.h> is newer, but several gnulib modules already assume it, so
it should be OK too.  I think GCC supplied its own <string.h> if the
system lacked one, so our "use GCC" solution should work even if use
<string.h>.

Another hosted header is <stdlib.h>.  It's included unconditionally in
a couple of modules, and nobody has complained so far, so I guess it's
OK to include that unconditionally too.

If this turns into a problem in the future, we can supply our own
<string.h> and <stdlib.h> modules, much as we have one already for
<stdbool.h>.  But with luck we won't need to bother.

> Any objections against this patch?

Not from me.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]