mailing list of musl libc
 help / color / mirror / code / Atom feed
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


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