> Would this difference explains why there is no redefinition linking
> error with musl, or am I missing something?
I don't know. I will ask people who know. It is strange indeed;
I didn't even notice that the strnlen sysdep was "no" with musl,
else I would have fixed it...
>What is the reason for clearing _POSIX_C_SOURCE from trystrnlen.c?
The set of functions made visible by a libc is generally bigger when
you do *not* define any POSIX or XOPEN macro: systems don't feel like
they have to respect a particular namespace, and export all they have,
or close to all they have. _POSIX_C_SOURCE usually means "only declare
what is strictly POSIX, and if the application is trying to use an
extension, it's an error".
This is true even for functions actually defined by POSIX, such as
futimens(), the openat() family of functions, and the whole
sys/socket.h family of functions; some (arguably old) libcs mistakenly
fail to expose them when POSIX macros are defined, but expose them
when no such macro is defined. Sometimes they also require a specific
extension macro to expose them. The biggest culprits of this are
Solaris, MacOS, and NetBSD. The only libcs I've never seen stray from
POSIX visibility rules are glibc and musl.
And so, when testing a function's existence, I usually remove all
POSIX macro definitions, assuming that the visibility will be higher
and the function has a higher chance of being detected - so the
system's function is used instead of the workaround.
In the case of strnlen, though, it appears that this assumption is
wrong. I just tested without the undefs, and unless I missed something
again, strnlen is correctly detected on all the systems that have it.
My bad then, it's a bug. The latest git head performs the trystrnlen.c
test without the undefs; please test it. If it works for you, I'll
release a new version of skalibs with the fix.
--
Laurent
Received on Sat Jan 13 2018 - 21:09:32 UTC