This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: need to define _ISOC99_SOURCE


On Wed, 26 Jul 2000, Bruno Haible wrote:

> What is the justification for requiring users to define special flags
> like _ISOC99_SOURCE ? These fgetwc etc functions were contained already
> in ANSI C Amendment 1, more than 5 years ago, and have been reaffirmed
> in ISO C 99, more than 6 months ago.

I had noticed this in a glance through the headers - I'll be going through
them more carefully against all C standard versions soon.

In this particular case, since <wchar.h> and <wctype.h> were first added
in AMD1, functions defined there should not be conditioned in them, just
as all headers define ISO C:1990 things unconditionally, headers such as
<unistd.h> define POSIX.1 things unconditionally, etc..

glibc claims to support in <features.h> the sets of symbols defined by
many different standards, though how correct the namespaces actually used
in each case actually are I don't know.

(The defintion of __USE_ANSI seems unnecessary: it is nowhere
used.  __USE_REENTRANT is only used twice; in posix/unistd.h to protect a
declaration of getlogin_r, it is bogus and should be replaced with an
appropriate POSIX version test.  In stdio/stdio.h it protects tmpnam_r,
but could be replaced by __USE_MISC as in libio/stdio.h.  So these could
probably go away, along with the _REENTRANT and _THREAD_SAFE feature test
macros for the user to define.)

> Or will gcc-3.0 define __STDC_VERSION__ >= 199901L, thus making the
> issue moot?

I doubt that GCC will make -std=gnu99 the default for a few years; I doubt
GCC 3.0 will even have full C99 support (unless more people start to work
on implementing it).

I think that support for strict 1990 standard support (-std=iso9899:1990)
will still be useful for some people for several years.  When GCC moves to
-std=gnu99 as the default instead of -std=gnu89 as now this will in effect
turn on the C99 support in glibc by default, but it would be quite
reasonable before then to add

# define _ISOC99_SOURCE 1

to the default defines in the case that no feature test macros or strict
standards conformance has been specified:

#if (!defined __STRICT_ANSI__ && !defined _ISOC99_SOURCE && \
     !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE && \
     !defined _XOPEN_SOURCE && !defined _XOPEN_SOURCE_EXTENDED && \
     !defined _BSD_SOURCE && !defined _SVID_SOURCE)
# define _BSD_SOURCE    1
# define _SVID_SOURCE   1
#endif

[ _POSIX_C_SOURCE also gets defined by default similarly. ]

For now, -std along with feature test macros provide adequate flexibility;
with GCC 3.0, -std=gnu99 will probably do what you want.  The present
<wchar.h> issue is just a simple bug: functions wrongly conditioned on
__USE_ISOC99.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]