<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - udev fails to build with uclibc" href="https://bugs.freedesktop.org/show_bug.cgi?id=73729#c19">Comment # 19</a> on <a class="bz_bug_link bz_status_RESOLVED bz_closed" title="RESOLVED WONTFIX - udev fails to build with uclibc" href="https://bugs.freedesktop.org/show_bug.cgi?id=73729">bug 73729</a> from <a class="email" href="mailto:nico.nelson-91c8b80@yopmail.com" title="Nico Nelson <nico.nelson-91c8b80@yopmail.com>"> Nico Nelson</a> <pre>(In reply to <a href="show_bug.cgi?id=73729#c18">comment #18</a>) > (In reply to <a href="show_bug.cgi?id=73729#c17">comment #17</a>) > > (In reply to <a href="show_bug.cgi?id=73729#c16">comment #16</a>) > > > (In reply to <a href="show_bug.cgi?id=73729#c15">comment #15</a>) > > > > well, then at least close it with WONTFIX. > > > > > > Whatever it takes... > > > > yes, that would have done it, if it wasn't for your comment below - and it > > seems one cannot reply without reopening, and as can't leave that comment > > as-is, i have to reopen... > > > > > > > > > that uclibc doesnt implement 100% of glibcs idiotic add-ons is definitely > > > > not a bug. > > > > > > The locale_t bits are POSIX btw. And "%m" and "secure_getenv()" are > > > certainly not idiotic. %m is a nice way to deal with the thread-unsafety of > > > strerror(). > > > > strerror() is not thread-unsafe when implemented properly (i.e. just > > returning a pointer to a readonly string). it's not uclibc's fault if glibc > > doesn't do so. > > Well, doing the read-only thing is kinda hard if you handle locale or if you > handle unexpected error numbers (which you need to stay compatible when the > kernel adds new error numbers). localized error messages are a bad idea to begin with. > > Also, given that you love POSIX so much, glibc is perfectly in line with > POSIX here: > > "The strerror() function need not be thread-safe." -- > <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html">http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html</a> > > I mean, I'd certainly prefer if it was thread-safe, but it isn't. > > Also, uclibc's strerror() is not thread-safe either: > > <a href="http://git.uclibc.org/uClibc/tree/libc/string/strerror.c">http://git.uclibc.org/uClibc/tree/libc/string/strerror.c</a> looks like you didn't see this part: #ifdef __UCLIBC_HAS_PRINTF_M_SPEC__ i compiled my uclibc with that "feature" disabled as it would bloat all my statically linked binaries. otoh since uclibc *can* be compiled with it activated, it should be easy to fix the locale specific build error, as it seems the --disable-localed option is not properly respected. and add something along the lines of #ifndef __GLIBC__ #define secure_getenv(foo) getenv(foo) #endif in utils.h + a note in README that for uclibc __UCLIBC_HAS_PRINTF_M_SPEC__ must be enabled, and everyone is happy again. > > (And let's also note that uclibc has %m, too: > <a href="http://git.uclibc.org/uClibc/tree/libc/stdio/_vfprintf.c">http://git.uclibc.org/uClibc/tree/libc/stdio/_vfprintf.c</a>) > > > > I mean, thigns are not "idiotic" just because uclibc doesn't implement them. > > > Maybe the thread and security issues don't matter to you, but they certainly > > > do matter to us. > > > > well, the idiotic bit is for example if strerror() is implemented by copying > > const strings to a static buffer instead of just returning the const string > > itself. however i highly doubt that glibc does so. > > so you're basically fixing an inexistant problem by using hacks - bravo! > > Well, glibc and uclibc are equally idiotic here then. indeed. fortunately musl libc isn't.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>