Re: [musl] Prototypes without implementations

[Rich Felker <dalias@libc.org>]

On Sun, Oct 27, 2024 at 12:08:25AM +0200, Thorsten Glaser wrote:
> On Sat, 26 Oct 2024, Markus Wichmann wrote:
> 
> >See above. Failing with ENOSYS and no side effects is a perfectly
> >conforming implementation of most POSIX functions.
> 
> Insisting on this ivory tower opinion will just make people
> mark your software as buggy and move on.
> 
> For most functions, it’s reasonable to check for presence,
> and if so, enable codepaths that do:
> 
> 	if (pselect(…) == -1) {
> 		if (errno == EINTR) {
> 			// special handling
> 		}
> 		err(1, "pselect");
> 	}
> 
> The vast majority of software, OSS and not, works this way.
> If a basic function in a standard is there it better function.
> 
> Linux’ getrandom() is an offensive exception to that and better
> stay the only one.

This thread has veered really off-topic. I haven't read it in full,
but based on what it seems to be about, a few remarks:

- I don't buy that ENOSYS buys you a license to omit parts of POSIX
  you don't want to implement. Yes there's license to have additional
  errors not defined in the standard, but the only reasonable
  interpretation is that these should be for concrete conditions that
  can be remedied. At the very least, an interface always failing is
  bad QoI. As an example, I don't claim running on a nommu system,
  where fork() will necessarily ENOSYS, gives a POSIX-conforming
  environment; it's a POSIX subset. IIRC part of the rationale text
  addresses that and agrees with my interpretation here.

- pselect ENOSYS? Come on. This is 2024, almost 2025, not 1999.
  (Unless I'm misremembering it was added in POSIX 2001.)

- Back to extension interfaces (or very recent standards) which might
  or might not be available at runtime: Whether availability of a
  particular such interface is reasonable to defer to runtime really
  depends on what the interface is and what it's being used for.
  Trying to make broad sweeping generalizations does not seem helpful,
  and particularly, does not seem relevant to the ioperm/iopl topic.

- That said, yes, whether an interface is available at the library
  level, and whether it works on the machine you happen to be running
  on later, can differ, and this is something where "musl policy"
  (using the term very loosely, in the sense of what we recommend to
  projects when trying to get something fixed) is that, unless the
  standard says the interface and functionality is always present, you
  should both check for it at configure-time/build-time, and be
  prepared at runtime for the possibility that it might not be
  supported or might not support all features on the running system. I
  would expect software using iopl/ioperm already needs to be prepared
  for the possibility that they could fail for permissions reasons,
  and should avoid calling them anyway unless it knows it needs to
  perform userspace hardware IO. So I'm not sure how this matters or
  how an ENOSYS here would be any different from EPERM -- it's just
  another reason you can't do IO as a user process.

Can we use the remainder of this thread for figuring out the real
status of this (what's with non-x86 archs that have the syscalls? are
they used? what about archs that don't use them? do they have you mmap
a device instead?) and whether there's some action that should be
taken, rather than rehashing broad philosophy? :)

Rich