[Top][All Lists]

[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: 02 Sep 2003 13:09:57 -0700
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Derek Robert Price <address@hidden> writes:

> What is this recommended mess from the Autoconf manual for, then?
> Systems where GCC is not assumed?

Yes.  This is because Autoconf still caters to a broader population
than gnulib: it still generates 'configure' files that are supposed to
work with K&R compilers.

> I thought the decision had been to assume a freestanding C89
> compiler (as opposed to GCC) and recommend compiling GCC when one is
> not available?

It's a bit tricky; let me try to explain better.

We decided to assume a freestanding C89 compiler so that we could
assume <limits.h>, <stdarg.h>, and <stddef.h>; many of the modules had
things like HAVE_LIMITS_H that weren't necessary.

I was dubious about assuming all the hosted headers, since I know that
many older hosts lack some of them.  However, as a practical matter,
several gnulib modules already assumed some of the hosted headers
(e.g., <errno.h>) and there's no practical problem with this, as these
headers have always been in all our porting targets.  (Similarly, many
modules assume <sys/types.h> even though it's not even in C99; that's
OK since <sys/types.h> has been around nearly forever.)

<string.h> and <stdlib.h> were more problematic.  They are not in Unix
Version 7, so they weren't universally available on ancient hosts.
However, they are both in SunOS 4 (the oldest platform still in
relatively-common use) so I think it's OK to assume them now, even if
their contents may not conform to the standard.  And some gnulib
modules (e.g., argmatch) already assumed both, and nobody was
complaining about them, so it seems OK to assume the existence of
<string.h> and <stdlib.h>.

Even if the include files exist, they may not conform to the C
standard.  However, GCC has a "fixincludes" script that attempts to
fix ANSI-conformance problems.  It is a bit of a hack, but I think we
can probably get away with assuming conformance to C89 or better in
<string.h> and <stdlib.h>, and ask people to use GCC (or fix their
include files manually) if they are on ancient hosts.

reply via email to

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