You are viewing airlied

airlied
airlied
:.:..:.

May 2014
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

airlied [userpic]
glibc - inconsistent interfaces due to arrogance

To start off, I don't actually mind arrogant people as long as they back their attitude up with some semblance of sanity, however arrogance without ability pisses me off, and it seems that its the number 1 trait to be a maintainer of glibc.

Today someone pointed out F_SETOWN_EX to me which I can use to fix a problem in the X server, however trying to use gettid made me realise why these guys are considered such fuckwits.

http://sourceware.org/bugzilla/show_bug.cgi?id=6399

WTF? glibc exposes 3 interfaces that need the result of gettid passed to them and internally relies on gettid to implement raise properly and it won't expose the interface. Notice in the bug he never addresses the problems, just closes it with "CLOSED ARROGANCE".

Other recent glibc fuckwittery includes the whole overlapping memcpy issues in F14 breaking flash for everyone, and trying to remove the rpc implementation a week before the F15 final release freeze, so that if the package had gotten in and packages that needed a rebuild for say a security fix would mean linking the fixed package against a different RPC library than the original which could cause untold pains.

So really if glibc could DIACF already thanks.

Comments

>he never addresses the problems, just closes it with "CLOSED ARROGANCE"
I feeel your pain, man.
I really do: http://sources.redhat.com/bugzilla/show_bug.cgi?id=5486

(Anonymous)
WONTFIX

Yeah, but also in this bug Drepper is rather polite if you compare to other bugs where he could say "never going to happen", and then abuse someone who points out why it needs to happen, still without really explaining why it caot/should ot be done. Then you only have to wait three years to see him come around and implement the functionality because he was force to (either by hitting the problem himself, or RedHat doing a decision that needed said functionality/arch working).
Happens all the time. He may have awesome skills when it comes to programming/libc/compilers, but he also have 0% social skills, at least when it comes to bugzilla.

(Anonymous)
Headbanging...

Drepper may be very technically skilled, but he's also a perfect example of why that is not enough to be a good maintainer. Too many people have received head injuries from banging their heads against the wall.... Even though I wish it wouldn't have to exist, eglibc is really needed.

(Anonymous)
Debian has a manpage for gettid

http://manpages.debian.net/cgi-bin/man.cgi?query=gettid&apropos=0&sektion=0&manpath=Debian+6.0+squeeze&format=html&locale=en

According to Debian, you should just use the syscall directly (SYS_gettid).

Heh, what else is new. If you look up the phrase "head up your ass" in a dictionary, you'll find a picture of Ulrich Drepper.

arrogance

"just closes it with "CLOSED ARROGANCE"."

i'm writing the change request to RH bugzilla team now...:)

(Anonymous)
eglibc

I'd suggest taking it up with eglibc, the people actually maintaining libc these days for most Linux distributions. I suspect you'll find more sanity there.

(Anonymous)
Re: eglibc

does it have a wrapper for gettid()?

(Anonymous)
Re: eglibc

I think he meant that if they does not already have that it would be easier to get them to implemnt one, then to get Depper to eve consider reopen that bug...

(Anonymous)

Whilst I'd ordinarily agree with you on glibc and Drepper, I'm not sure that memcpy is the best example to pick. So far as I know, every specification that has included memcpy has always included the "must not overlap" requirement, and the memmove option has always been available, so it's pretty clearly Flash that's to blame on that one. I find it hard to be sympathetic towards software that's blatantly violating a specification and getting away with it by fluke.

(Anonymous)

True.

(Anonymous)
backwards compatible

Yeah, memcpy may not be the best example, but all else is fully valid, and I guess you can find a couple more.

I do not really remember where the whole memcpy thing ended, tho. IIRC last time I heard something there was a discussion on how necessary that change was. Mostly because it broke apps without giving no apparent gain. It was more like "aww, look at those fancy things new Intel-processors can do, lets utilize that", then "aww, by doing these new fancy things glibc got SO MUCH STABLER/FASTER/SMALLER!", which tend to be bad practice (i.e. if something aint broke, do not fix unless there are gains since more things will break in the process).

Re: backwards compatible

I actually found a bug in X's software renderer recently where we were using memcpy even though the caller might have given us overlapping regions. With the new memcpy optimization in glibc, that meant misrendering in a very obvious way: right-to-left scrolling or window move would get corrupted by propagating some pixels from the right part of them image repeatedly left. Makes total sense, the new memcpy runs from high addresses to low.

Obviously the answer is "just use memmove", and I did at first, but that ended up cutting the performance of that path in half. Once I did the pointer math to call memmove only when overlapping I got my factor of two back.

So, yeah, it's actually a real win.

(Anonymous)
Re: backwards compatible

memmove should be implementing the "if non-overlapping call memcpy" optimization itself.

(Anonymous)

> I find it hard to be sympathetic towards software that's blatantly
> violating a specification and getting away with it by fluke.

But, but...
Software which doesn't do anything to notify programmer
when aforementioned semantic violation happens should not
raise sympathy either.

--adobriyan

(Anonymous)

memcpy has no "must not overlap" requirement. It just gives undefined results for overlapping memory regions.

That being said, code which uses memcpy for overlapping memory regions deserves to break in the worst imaginable way.

(Anonymous)
flash wasn't the only program affected

The memcpy change exposed other bugs as well. For example, it exposed a bug in glibc itself. (Unfortunately, I'm too lazy to find the bugzilla entry for that).

It feels good, but it's stupid to blame it all on Adobe.

-error27

(Anonymous)
glibc has own timeline

Have no idea why glibc people should even bother to check when Fedora does anything. Fedora is free to use older glibc with rpc being there.

This is fedora "fuckwittery" and not glibc one.

Re: glibc has own timeline

maybe in the world you live in you have no idea where Linux software comes from, you probably think it all springs from Mark Shuttleworths arse fully formed.

However the Fedora glibc maintainers are the same people as the upstream glibc maintainers for all intents and purposes. the glibc release cycle for years has matched the Fedora release cycle. Anyone with half a brain could research this and not look stupid, lucky you didnt leave a name on the post to point out your own idiocy.