Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8d50e426-e965-441c-94a7-a6ef16bd3e2b@arm.com>
Date: Sat, 11 Apr 2026 18:03:14 +0200
From: Gilles Peskine <gilles.peskine@....com>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: Detecting getrandom() or syscall()

Thanks for the reply!

On 11/04/2026 03:54, Rich Felker wrote:
> The historical and current way this is recommended to be done is with
> compile and link tests at build time. This can be done with autoconf,
> or on your own with a build rule (e.g. in a makefile) that executes
> the compile or link attempt command and generates a header fragment
> from the exit status. I imagine cmake and other build systems some
> folks prefer nowadays have similar facilities.
That is the historical way, yes, but mostly to cope with the lack of
standardization of 1980s Unix systems. Compile-and-run isn't doable
anyway on embedded systems where one is usually cross-compiling.
I've found that compile-only isn't reliable anyway in this specific
case (with some other libc, syscall() was declared, but was not
available at link time). Compile-and-link might work on Linux, but
even there I'm not sure. It certainly doesn't work on embedded systems
where one links a single code image, and our build scripts don't know
how to link a whole system image. In any case, I don't think we will
ever have enough developer time to maintain a compile-and-link platform
discovery tool for a small subset of our users.

> There is a proposal I put forth on the libc-coord mailing list in
> 2020, titled "Macro-based advertisement of libc extensions", for
> implementors to agree on a naming convention for macros that would
> declare the presence of nonstandardized but common interfaces and
> features, so that you could use preprocessor conditionals on these
> directly without having to run your own tests, and so you could know
> the availability of untestable things (things where any test would
> produce undefined behavior).

I agree that something like
     #if __has_function_syscall
is the way to go! So what macro can we use to test for the presence of
syscall() on musl or elsewhere?

-- 
Gilles

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.