This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
Re: C9x conformance check
- To: Zack Weinberg <zack@rabi.phys.columbia.edu>
- Subject: Re: C9x conformance check
- From: Ulrich Drepper <drepper@cygnus.com>
- Date: 31 Aug 1998 12:43:00 -0700
- Cc: libc-hacker@cygnus.com, egcs@cygnus.com
- References: <199808282351.TAA24757@rabi.phys.columbia.edu>
- Reply-To: drepper@cygnus.com (Ulrich Drepper)
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 `------------------------