Re: Header conformance/improvements (part 2)

[Rich Felker <dalias@libc.org>]

On Fri, Feb 23, 2018 at 02:48:10PM -0500, Daniel Sabogal wrote:
> On Fri, Feb 23, 2018 at 2:20 PM, Rich Felker <dalias@libc.org> wrote:
> > On Fri, Feb 23, 2018 at 01:32:49PM -0500, Daniel Sabogal wrote:
> >
> >> tar.h
> >> -----
> >> * TSVTX
> >> this constant is XSI-shaded
> >> glibc exposes it with _XOPEN_SOURCE
> >
> > tar.h is not governed by any modern standard. Not sure if there's any
> > reason to change it. I feel like making it depend on FTMs is wrong.
> 
> I see that tar.h is specified here:
> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/tar.h.html#tag_13_73

Uhg, how could I forget? OK, I'll fix this one.

> >> signal.h
> >> --------
> >> * int sigqueue(pid_t, int, /* const */ union sigval);
> >> harmless; it just doesn't reflect http://austingroupbugs.net/view.php?id=844
> >
> > I don't think this is any actual diference; the const keyword is a nop
> > there. Issue 844 is just about the standard gratuitously including a
> > do-nothing keyword there.
> 
> Right. Keeping the qualifier here is harmless.

Oh, I read it backwards and thought we lacked the const. I'm in favor
of removing redundant/meaningless stuff in declarations. BTW all
instances of __restrict except one or two (pointer-to-__restrict) are
also of this type; they're meaningless in the declaration and perhaps
should be removed.

> >> inttypes.h
> >> ----------
> >> * wchar_t
> >> this symbol is exposed to the ISO C namespace
> >> AFAICT, this symbol is CX-shaded, and according to n1570 7.8.2.4p1,
> >> it seems to be intended that <stddef.h> be included to expose wchar_t
> >
> > Ah. This is problematic because functions declared in inttypes.h
> > require wchar_t to prototype. Of course a shadow name for the same
> > type can be defined (like how va_list is handled) but it's ugly...
> >
> >> wchar.h
> >> -------
> >> * FILE
> >> this symbol is exposed to the ISO C namespace
> >> AFAICT, this symbol is CX-shaded, and according to n1570 7.29.2.1p1,
> >> it seems to be intended that <stdio.h> be included to expose FILE
> >
> > Similar issue. It could be fixed with a shadot typedef or explicit
> > "struct _IO_FILE". The latter is ugly and something of a violation of
> > the abstraction, I think..
> 
> Indeed. I think ISO C should have exposed these data types.

I agree. Maybe we should change it though. I'll think about it. I know
there were tests (I think gcc fixincludes mess) flagging spurious
exposure of va_list as a bug, and in principle someone might decide to
do the same here, but maybe we should wait to make any change until
if/when there's a problem.

Rich