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 220.127.116.11p1, > >> 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 18.104.22.168p1, > >> 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.