Date: Fri, 23 Feb 2018 14:48:10 -0500 From: Daniel Sabogal <dsabogalcc@...il.com> To: musl@...ts.openwall.com Subject: Re: Header conformance/improvements (part 2) 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 >> stropts.h >> --------- >> * RPROTMASK >> this constant is non-standard and not reserved >> glibc exposes it with _GNU_SOURCE > > Aside from the ioctl function, this is all deprecated/removed > functionality, not governed by any profile of the standards we claim > to support. Not sure if there's any reason to change it. This header is obsolescent so it probably doesn't matter. >> 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. >> inttypes.h >> ---------- >> * wchar_t >> this symbol is exposed to the ISO C namespace >> AFAICT, this symbol is CX-shaded, and according to n1570 126.96.36.199p1, >> 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 188.8.131.52p1, >> 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.
Powered by blists - more mailing lists
Powered by Openwall GNU/*/Linux - Powered by OpenVZ