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
