[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180310231436.GX1436@brightrain.aerifal.cx>
Date: Sat, 10 Mar 2018 18:14:36 -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:20:49PM -0500, Rich Felker wrote:
> On Fri, Feb 23, 2018 at 01:32:49PM -0500, Daniel Sabogal wrote:
> > Here's a list of observations from musl's headers.
>
> Thanks!
>
> > 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.
>
> > unistd.h
> > --------
> > * F_LOCK, F_TEST, F_TLOCK, F_ULOCK
> > these constants are XSI-shaded
> > glibc exposes them with _XOPEN_SOURCE
>
> Indeed they go with lockf and should be in the #ifdef with it.
>
> > 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.
>
> > 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.
>
> > arch/*/bits/termios.h
> > ---------------------
> > * NLDLY, NL0, NL1
> > * CRDLY, CR0, CR1, CR2, CR3
> > * TABDLY, TAB0, TAB1, TAB2, TAB3
> > * BSDLY, BS0, BS1, FFDLY, FF0, FF1
> > these constants are XSI-shaded
> > (so are VTDLY, VT0 and VT1, but the prefix "V" is reserved by posix)
> > glibc exposes them with _XOPEN_SOURCE
>
> This probably should be fixed; unfortunately it means moving some FTM
> logic into bits headers or refactoring.
>
> > limits.h
> > --------
> > * PAGE_SIZE
> > * NL_LANGMAX
> > * NZERO
> > these constants are XSI-shaded
> > glibc exposes them with _XOPEN_SOURCE (except PAGE_SIZE)
>
> OK, for PAGE_SIZE, the arch bits should be changed to define PAGESIZE
> instead of PAGE_SIZE and the top-level limits.h logic should be
> reversed to define PAGE_SIZE in terms of PAGESIZE. The others are
> defined in top-level file anyway and just need to be moved under
> proper FTMs.
Fixing all of the above, including tar.h.
> > sys/socket.h
> > ------------
> > * AF_* excluding AF_{INET,INET6,UNIX,UNSPEC}
> > * MSG_* excluding MSG_{CTRUNC,DONTROUTE,EOR,OOB,NOSIGNAL,PEEK,TRUNC,WAITALL}
> > * PF_*
> > * SCM_* excluding SCM_RIGHTS
> > * SO* excluding SOCK_{DGRAM,RAW,SEQPACKET,STREAM},
> > SO_{ACCEPTCONN,BROADCAST,DEBUG,DONTROUTE,ERROR,KEEPALIVE,LINGER,OOBINLINE,RCVBUF,RCVLOWAT,RCVTIMEO,REUSEADDR,SNDBUF,SNDLOWAT,SNDTIMEO,TYPE},
> > SOL_SOCKET, and SOMAXCONN
> > * CMSG_* excluding CMSG_{DATA,NXTHDR,FIRSTHDR}
> > these constants/macros are reserved by an XSI-shaded prefix
> > changing this might be too intrusive; glibc just exposes them
>
> This is surprising. I doubt it would hurt to change, since little
> stuff builds with base POSIX profile anyway, but I'm not in a hurry to
> make changes here if not needed.
Leaving this for now. Will revisit if there's demand.
> > 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..
Leaving these alone too unless there's demand, for the reasons
discussed before.
Thanks for the reporting!
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.
