[systemd-bugs] [Bug 73729] udev fails to build with uclibc

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73729

--- Comment #18 from Lennart Poettering <lennart at poettering.net> ---
(In reply to comment #17)
> (In reply to comment #16)
> > (In reply to comment #15)
> > > 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." --
http://pubs.opengroup.org/onlinepubs/9699919799/functions/strerror.html

I mean, I'd certainly prefer if it was thread-safe, but it isn't.

Also, uclibc's strerror() is not thread-safe either:

http://git.uclibc.org/uClibc/tree/libc/string/strerror.c

(And let's also note that uclibc has %m, too:
http://git.uclibc.org/uClibc/tree/libc/stdio/_vfprintf.c)

> > 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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20140117/f3885833/attachment-0001.html>