Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180223192049.GI1436@brightrain.aerifal.cx>
Date: Fri, 23 Feb 2018 14:20:49 -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 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.

> 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.

> 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..

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.