[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFhhQJRPgJiC_bNLW0ra+-VLPra4gVzihsgd_dwxKbZZNqP=7Q@mail.gmail.com>
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 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.
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.
