Re: C9x conformance check

[Zack Weinberg <zack@rabi.phys.columbia.edu>]

On 31 Aug 1998 12:43:00 -0700, Ulrich Drepper wrote:
>Zack Weinberg <zack@rabi.phys.columbia.edu> writes:
>
>> egcs 1.0.3/x86 #defines i386 and i486 even if -undef is given.  (I dimly
>> remember this was to work around problems with Imake?)
>
>Yes, unfortunatelz.  This is why we have in the isomac program this
>code to ignore this error.

I realize this may be hard, but couldn' they be left in with -ansi and taken
out with -undef?

>> Problems which are libc's fault:
>> 
>> ctype.h: isblank() is under _GNU_SOURCE not _ISOC9X_SOURCE.
>
>isblank() is not in ISO C 9x.  It's reallz a GNU invention.

It's in the April draft: "7.3.1.3 The isblank function"

>> stdio.h: stdin, stdout, stderr are supposed to be macros.
>
>According to what standard?  ISO C and Unix98 say they have to be
>expressions of type "FILE *".

C9x April draft, 7.13.1 para 3 lists them as macros.

>> stdlib.h: strtof, strtold are under _GNU_SOURCE not _ISOC9X_SOURCE.
>
>This is correct.  Both are inventions by me.

April draft sections 7.14.1.6 and 7.14.1.7.  The committee must like your
inventions.

>> time.h: zonetime() is not implemented.
>
>Right.  I rather wait to do any more work onthe time stuff from c9x.
>There are many people unhappy with the current specs.  Maybe it'll
>change.

Ok.

>> wchar.h: The wide I/O functions and wcsftime/wcsfxtime are not implemented.
>
>They will follow as soon as I have wide char streams.

Ok.

>> wctype.h: iswblank() is under _GNU_SOURCE not _ISOC9X_SOURCE.
>
>Correct.  See above.

7.18.2.1.3.

>> complex.h: The CX_LIMITED_RANGE macros are nowhere in my copy of the
>> standard.
>
>This is no macro, it's a pragma.  ISO c9x 7.3.4.

I know - but our math.h defines CX_LIMITED_RANGE_ON, CX_LIMITED_RANGE_OFF,
and CX_LIMITED_RANGE_DEFAULT (to nothing)

>> inttypes.h: #defines intptr_t (for coordination with unistd.h; this should
>> be __intptr_t_defined).
>
>Why?

Well, my program is really picky, and elsewhere we use __foo_defined; why
have two idioms?

>> stdbool.h does not exist.  This header is trivial but we should agree on who
>> provides it.
>
>It does exist in egcs.

Right - Andreas mentioned this.

>> complex.h #defines `complex'.  (This is arguably fine.)
>
>This should be ok.

Yeah. I misread the standard.

>> stdarg.h provides stdio.h with an internal name for va_list: __gnuc_va_list.
> 
>> Other compilers can't be expected to know that.  __va_list is perhaps more
>> reasonable?
>
>I don't see the problem.  We define _G_va_list.

_G_config.h doesn't change if you suddenly start using another compiler.

>> Also, stdarg.h prototypes va_end (as well as #defining it) which is ok
>> except that it assumes va_end() exists in the library, which it doesn't.
>
>Va_end is defined as a macro.  But it is no problem to have a
>prototype with is shadowed by the macro if a fucntion helps to
>implement the macro more efficiently.

All the va-* headers do something like this:
void va_end (__gnuc_va_list);
#define va_end(AP) ((void)0)

Neither libc nor libgcc implements a va_end function, so if I suppress the
macro I'll get a link error.  The standard does say it's undefined behavior
if I suppress the macro, but I think it would be polite to have a no-op
va_end function somewhere - probably in libgcc.

I'm going to do some work on the gcc headers - they're a mess.

zw