[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180225001745.GM1436@brightrain.aerifal.cx>
Date: Sat, 24 Feb 2018 19:17:45 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Header conformance/improvements (part 2)
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@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
