Gary E. Miller via devel writes: > I was not talking about strerror_r().
But this thread is about that exact function. > I was talking about strnXXX() > and struct ifreq. If you talk about strnlen, it's not used in ntpsec (current master). The other strnXXX functions are ANSI C and don't need a header or library (but you mostly shouldn't use them for other reasons of course). I note in passing that strncpy is used anyway in the json example code. The ifreq struct innards are OS specific, so you need a shim anyway if you must go in directly. But you shouldn't poke it like that and use the accessor macros from net/if.h instead (these already are in the XTI POSIX extension I believe and should be old enough to be covered by the POSIX version that ntpsec targets I'd think). The current Linux version of that doesn't need any feature test macros to activate those definitions, btw. It's entirely possible that other systems or older Linux versions did, especially when IPv6 support was new. Also, current Linux addresses this problem in a different manner, see linux/libc-compat.h (in other words, _GNU_SOURCE is no longer the actual guard for the struct members and you'll be much better off using a more specific feature test). That leaves the BSD jail functions that I know nothing about, but I'm dubious about these needing _GNU_SOURCE. THey may become visible as a side effect of _GNU_SOURCE, but again there should be a more specific feature test. > Not at all what I meant. Flexible about what NTPsec builds on, not > flexible about the end result. You were arguing for defining _GNU_SOURCE, were you not? >> You already try to use both > > Uh, not me white man.... Not my code. That is relevant to the discussion how? > Yes, Hal is the one working on it. James also did a lot of work on > strerror_r(). I'm just staying out of their way. Yet you keep arguing that _GNU_SOURCE should or could be defined, which is the source of the problems in issue #614. You can't be POSIX compatible and define _GNU_SOURCE at the same time (and that already assumes that the system libc either is a sufficiently modern glibc version or some other library that took some pains to emulate glibc quirks to provide portability for ATWIL[*] programs). [*] All the world is Linux. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
