From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: Re: [musl] Prototypes without implementations
Date: Sat, 26 Oct 2024 10:26:16 +0200 [thread overview]
Message-ID: <ZxynqAh9f332yOSu@voyager> (raw)
In-Reply-To: <emc51f6a2f-139b-4697-abbd-aee651abe1d9@84cd4237.com>
Am Sat, Oct 26, 2024 at 01:21:23AM +0000 schrieb Laurent Bercot:
> When the libc provides no implementation, a sysdep test can compile
> and link a program using the API, and conclude that the functionality
> doesn't exist when the link fails. This works when cross-compiling.
>
> When the libc provides an ENOSYS implementation, the link will succeed,
> and a sysdep test needs to *run* a program to check that the
> functionality works correctly. This is not possible when cross-compiling.
>
I don't understand the remainder of the thread as it is now, because
normally we consider the above behavior to be insanity. 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().
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. Writing your software in the above manner is therefore
not sensible. 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.
But maybe the system calls talked about here are ultra-special in some
way.
Ciao,
Markus
next prev parent reply other threads:[~2024-10-26 8:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-25 20:01 Alyssa Ross
2024-10-25 20:10 ` Rich Felker
2024-10-25 21:38 ` Alyssa Ross
2024-10-26 1:21 ` Re[2]: " Laurent Bercot
2024-10-26 1:57 ` Thorsten Glaser
2024-10-26 2:11 ` Rich Felker
2024-10-26 8:26 ` Markus Wichmann [this message]
2024-10-26 10:28 ` Re[2]: " Laurent Bercot
2024-10-26 13:22 ` Markus Wichmann
2024-10-26 22:08 ` Thorsten Glaser
2024-10-26 23:03 ` Rich Felker
2024-10-30 9:28 ` Alyssa Ross
2024-10-30 12:37 ` enh
2024-10-26 23:35 ` Re[2]: " Laurent Bercot
2024-10-27 22:43 ` Yao Zi
2024-10-26 10:10 ` Robert Clausecker
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=ZxynqAh9f332yOSu@voyager \
--to=nullplan@gmx.net \
--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).