On 2018-01-13 21:09, Laurent Bercot wrote:
>
> > 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.
Thanks for the detailed explanation. I tested the latest git head and
the problem is solved. Thank you!
Regards,
--
ELB
Received on Sun Jan 14 2018 - 17:29:20 UTC