From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12548 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Header conformance/improvements (part 2) Date: Sat, 24 Feb 2018 19:17:45 -0500 Message-ID: <20180225001745.GM1436@brightrain.aerifal.cx> References: <20180223192049.GI1436@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1519517763 5727 195.159.176.226 (25 Feb 2018 00:16:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 25 Feb 2018 00:16:03 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-12564-gllmg-musl=m.gmane.org@lists.openwall.com Sun Feb 25 01:15:59 2018 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1epjyw-0000sn-Tj for gllmg-musl@m.gmane.org; Sun, 25 Feb 2018 01:15:58 +0100 Original-Received: (qmail 3629 invoked by uid 550); 25 Feb 2018 00:17:58 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3599 invoked from network); 25 Feb 2018 00:17:57 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:12548 Archived-At: On Fri, Feb 23, 2018 at 02:48:10PM -0500, Daniel Sabogal wrote: > On Fri, Feb 23, 2018 at 2:20 PM, Rich Felker 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 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 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