Re[2]: [musl] Prototypes without implementations

["Laurent Bercot" <ska-dietlibc@skarnet.org>]

>I don't understand the remainder of the thread as it is now, because
>normally we consider the above behavior to be insanity.

  Who's "we"?


>  Just because a
>function exists in the lib does not mean it will succeed at run-time.
>This is already the case with functions like getrandom() or pselect().

  getrandom() is part of the problem, yes - a function that you cannot
test for at link time and that you have to make depend on a kernel
version in order to use. But because the problem already exists doesn't
mean it's a good idea to add to it.

  pselect() is posix, it has a specification. If your pselect() isn't
doing what it's supposed to, then your implementation is nonconformant.
Yes, nonconformant systems are ubiquitous too, that's a problem too,
and that's why we test stuff, but standards are still a good thing.
strlen() works everywhere and you don't need to test for it. (Yes,
it's a low bar. And it's not true for strnlen(). Don't get me started.)


>Even if you could run run-time tests, just because it succeeds at
>configure time does not mean it succeeds at any later date. And
>conversely, just because it fails at configure time does not mean it
>cannot succeed.

  The point isn't to test for "success" or "failure" (unless you've
found a solution to the halting problem, in which case I'm definitely
interested). The point is to have a decent heuristic for whether a
given function, identified by its name and signature, exists in your
system and has a reasonable chance of doing what you think it will do.
Is it perfect? No. Do we have a better way of writing portable software
that does not involve starting every single executable with a battery
of tests? Also no.


>  Writing your software in the above manner is therefore
>not sensible.

  Every single project using a configure script such as one created by
GNU autoconf, or a build system generator such as cmake or meson, is
therefore not sensible. That's fair, but maybe we should still try to
avoid breaking them?


>  Especially since the functions talked about here are
>system calls that on some architectures have been stubbed out in the
>kernel, so the run-time behavior depends on run-time kernel version.

  That's why, unfortunately, some functionality has to be documented as
depending on a run-time kernel version. It would be nice if we could
minimize the occurrences of having to document a dependency to a run-
time libc version, too.

--
  Laurent