Re: C9x conformance check

[Ulrich Drepper <drepper@cygnus.com>]

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.

> limits.h does not define LLONG_MIN, LLONG_MAX, or ULLONG_MAX.

Yep, I'll prepare a patch for this along with the other ISO C 9x stuff.

> stdarg.h does not define va_copy.

Well, we have __va_copy.  I added this macro a long time ago when the
draft stated this is the name to be used.  Since it's there and never
will go away I want to avoid adding va_copy since the draft might
still change.

> -aux-info has a bug: if you do
>   typedef struct TAG { ... } NAME;
>   int foo (NAME x);
> then -aux-info reports
>   int foo (TAG x);

Hard to fix.

> 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.

> math.h:  isinf() should be a macro; furthermore, it's hiding under
> __USE_MISC.

Corrected.  The old implementation is __USE_MISC is still available
but will be hidden by the macros for ISO C 9x.

> scalb(), scalbl(), scalbf() should be under _BSD_SOURCE; C9x only has
> scalbn().

Right.  They once were in c9x.

> C9x specifies gamma(); libc only has tgamma().
> 

Andreas already answered this.  tgamma() is the correct definition.

> signal.h: unconditionally prototypes pthreads functions due to
> bits/sigmask.h.

I think I've fixed this.

> 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 *".

> vscanf, vfscanf, vsscanf are under _GNU_SOURCE not _ISOC9X_SOURCE.

Corrected.

> fgetpos, fsetpos are only provided if _LARGEFILE_SOURCE is defined.
> (Weren't these in C89?)

Yes.  I've corrected this.

> stdlib.h: strtof, strtold are under _GNU_SOURCE not _ISOC9X_SOURCE.

This is correct.  Both are inventions by me.

> 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.

> wchar.h: The wide I/O functions and wcsftime/wcsfxtime are not implemented.

They will follow as soon as I have wide char streams.

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

Correct.  See above.

> 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.

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

Why?

> PRIiMAX, PRIXMAX, PRIiPTR, PRIXPTR, and most of the SCN* macros are missing.

Corrected.

> tgmath.h: the fma() macro is missing.

Well, there are many problems in the macros.  I'm correcting them currently.

> FLT_EVAL_METHOD is in math.h; it belongs in float.h.

You're right.  I try to get a patch in ASAP.

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

It does exist in egcs.

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

This should be ok.

> 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.

> 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.


Thanks for the analysis.

-- 
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------