From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/12542 Path: news.gmane.org!.POSTED!not-for-mail From: Daniel Sabogal Newsgroups: gmane.linux.lib.musl.general Subject: Re: Header conformance/improvements (part 2) Date: Fri, 23 Feb 2018 14:48:10 -0500 Message-ID: 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="UTF-8" X-Trace: blaine.gmane.org 1519415185 29767 195.159.176.226 (23 Feb 2018 19:46:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Feb 2018 19:46:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-12558-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 23 20:46:21 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 1epJIT-0007Jx-3l for gllmg-musl@m.gmane.org; Fri, 23 Feb 2018 20:46:21 +0100 Original-Received: (qmail 3761 invoked by uid 550); 23 Feb 2018 19:48:24 -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 3741 invoked from network); 23 Feb 2018 19:48:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=01DrI81/Hdb+3RbLnZZhu4JO6Pa8JsmdrY56wNJEgFM=; b=LU3XFqRQfmNlh/KIJ4f1l3PJ78pKGknUKuniptU7tsQWKHJoKNzBjFsYk6VJsy+TIj KbHKAK1LQpeoJOMG8byTObUdbszV3PulhTI1q5pKoHRjx9oxB3pXHTHfXa2IlRgPF8Hb 5dVk7uodqCA7umPxHSO7jaqa6GuwhShtyyrsewDIthS08FgC8p/CUFUniSGoAzI60x7I ruS4IWNhwOTkxuHud/5mVCgLLRAMFytBBxUVDlPFysQlURnMmJVxtC3KbEwVCC9Wa2Zy pSz+5yuRO3InyKL5ZTxqNIbBs/OKmvHPcyoAwyQ6y9Yomc9esQr2PR14J6YLRAKKRdFu dQTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=01DrI81/Hdb+3RbLnZZhu4JO6Pa8JsmdrY56wNJEgFM=; b=dcDTvdSOlJVCHDI6M4sBUstt9MZ9CSjWpCg4pNFgkmwzyJYzdQ+e8ROgaD5gC1SLEd TUAfxEF/IvLhkhRX5v1Noy+GzIJ0EBj4RxvZDtD8GMea9pa4M0r4u5f7umr7DV4xcbLJ EL4XvPzpp+zh3TTcJiaSP7Xv2ZZRZMLA4WeEai8bKgYvUx35nMLBTE2XeSu+8PmiAlkR t+lU/ZFBcfI3LiS9X5303hHhOkAhpboxEPsfj2UIJGqPSVhNpmg3VVF7eEZjHur5MzRm 4q+/MzaWJflNqQjfyUjU5Q70qrOCt6KrJysD8vk+dvO2k6kVLhoACSpyDjqaFHFwITGj GlIQ== X-Gm-Message-State: APf1xPBtL+In+B65TCC36KJ3C+9y+4cSMQhDuJ43CFPUwamn66ucvelr Py4DOTReTj0Q1/uXCPlK22FCKELm63+89hdym6S5Sg== X-Google-Smtp-Source: AG47ELvj2KWHNJL9IhdWXeQPD/tLOZewxgi6/8VleH2WiyY977A5OMpZ0B3pwfjQIEZ5muEktevU6B1AMxDLTyjDLqk= X-Received: by 10.202.180.4 with SMTP id d4mr462993oif.16.1519415291107; Fri, 23 Feb 2018 11:48:11 -0800 (PST) In-Reply-To: <20180223192049.GI1436@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:12542 Archived-At: 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 >> 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 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.