[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <emc3229b12-3f5c-4847-9cc7-49c0f43ca089@b9cddb74.com>
Date: Sat, 26 Oct 2024 10:28:38 +0000
From: "Laurent Bercot" <ska-dietlibc@...rnet.org>
To: musl@...ts.openwall.com
Subject: Re[2]: Prototypes without implementations
>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
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.
