<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#c18">Comment # 18</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:lennart@poettering.net" title="Lennart Poettering <lennart@poettering.net>"> Lennart Poettering</a> <pre>(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). 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> (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.</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>