From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Header conformance/improvements (part 2)
Date: Fri, 23 Feb 2018 14:20:49 -0500 [thread overview]
Message-ID: <20180223192049.GI1436@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAFhhQJQMxNrxKJ=W7r4qBh=x7sY-Ebd6R3=XwKqJJp_q5PkH9Q@mail.gmail.com>
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
next prev parent reply other threads:[~2018-02-23 19:20 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-23 18:32 Daniel Sabogal
2018-02-23 19:20 ` Rich Felker [this message]
2018-02-23 19:48 ` Daniel Sabogal
2018-02-25 0:17 ` Rich Felker
2018-02-25 8:07 ` Jens Gustedt
2018-03-10 23:14 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180223192049.GI1436@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).