Re: Updated glibc header namespace / C standards comparison

[Ulrich Drepper <drepper at redhat dot com>]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> complex.h
> =========
> 
> Some inline functions use ~ for complex conjugation; as this is a C99
> constraint violation (6.5.3.3p1), __extension__ should probably be
> used here.

No.  The compiler does not complain even in pedantic mode.

> inttypes.h
> ==========
> 
> This header should not declare the type wchar_t.
> 
> The values of WCHAR_MIN and WINT_MAX are wrong.  See 7.18.3p4 and
> footnote 219.  The values are the limits of the integer types involved
> and need not be valid as wide characters.  (AMD1 may be clearer than
> C99 on the meaning of WCHAR_MIN, there in <wchar.h>.)

What do you think is wrong.  I have no idea what you mean.

> time.h
> ======
> 
> CLOCKS_PER_SEC should be of type clock_t for C99 - on x86 Linux, this
> is `long int' rather than the present `int' type of CLOCKS_PER_SEC.
> 
> Should not declare clockid_t or timer_t.

I should have corrected these now.

> This header should not declare FILE.

Heh???  We need a forward declaration since otherwise #include
<wchar.h> fails unless you include <stdio.h> first.  I'll not add such
artificial problems.

> The following functions are in AMD1 and should be declared by this
> header when __STDC_VERSION__ >= 199409L, not just for C99: fwprintf,
> fwscanf, wprintf, wscanf, swprintf, swscanf, vfwprintf, vwprintf,
> vswprintf, fwide.

I don't plan to add yet another feature macro for AMD1.  It's useless.
There is nowhere a word that the library claims to support AMD1.  I
contains the functions introduced in the ammendment but support is
only there for C99 and C89 (the latter with restrictions as well).

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------