| |||||||||||||
A turning point for GNU libcA turning point for GNU libcPosted Mar 28, 2012 19:20 UTC (Wed) by wahern (subscriber, #37304)In reply to: A turning point for GNU libc by arjan Parent article: A turning point for GNU libc
That doesn't make any sense. Almost _all_ C routines continue on their merry way on undefined behavior.
The difference between strlcpy is that the behavior is well-defined as far as the language is concerned. The bad behavior (if truncation is undesired) is between chair and keyboard, and that's a huge step forward from the mess that traditional string routines have _actually_ made.
And truncation isn't silent: if (sizeof buf <= strlcpy(buf, str, sizeof buf)) oops("truncated!");
There, happy?
Most unix systems have strlcpy except Linux and compatriots like HP/UX. Nobody would have even questioned the utility of it if Drepper hadn't been so stubborn. And now somehow strlcpy() is faulted for supposed flaws that exist in almost all C routines, and are _especially_ egregious in the ones that Drepper proposed as alternatives. Just the other week on stackoverflow I saw someone post a memccpy() "alternative" which contained an off-by-one buffer overflow. (They apparently thought memccpy returned a pointer to the terminal character, not a pointer after the terminal character.)
Ridiculous.
And alternatives like strcpy_s from Microsoft are even more idiotic. Have you ever even tried to use them? The entire Annex K is stupid, and not even Microsoft supports the entire Annex even though they sponsored it.
People are entitled to their opinions, but this particular opinion just causes way too much headaches for too many people. You don't see systemd haters trying to keep systemd from shipping, do you? They just don't want to be _forced_ to use systemd. Nobody is forcing you to use strlcpy.
(Log in to post comments)
A turning point for GNU libc Posted Mar 28, 2012 20:03 UTC (Wed) by arjan (subscriber, #36785) [Link]
I would argue that the whole debate has shown that it's not a clear cut good API... and glibc, with its compat promise, does well to be conservative about adopting a solution.
(having been on the receiving end of such 'security scanner fixes' introducing more bugs than the original code had... I'm no big fan of either strncpy or strlcpy as replacement for strcpy.... especially since the linux strcpy is checking by itself in most of the critical cases already)
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 12:58 UTC (Fri) by cjcoats (guest, #9833) [Link] But see this discussion about GLIBC memcpy() changes at Version 2.11 breaking many existing executableshttps://bugzilla.redhat.com/show_bug.cgi?id=638477with Linus' performance-evaluation (proved it did not create the claimed speedup, and provided alternatives) and remarks about breaking those existing executables (turns out Flash was the most prominent culprit but there were lots of others). [Warning: there's a lot of stuff here...] And Drepper not only did not care: he said he did the right thing! FWIW
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 15:05 UTC (Fri) by khim (subscriber, #9252) [Link] Generally compatibility is guaranteed only if programmer follows guidelines. And in this sense Drepper has a point: the memory areas should not overlap. Use Sometimes, if there are a lot of broken programs, bug-to-bug compatibility is important enough to go further - and this is example what happened here in the end as you can see here.
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 17:37 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
that's a valid argument if the change improves something, but if (as in this case) the change doesn't give any performance improvement, the only 'advantage' of the change is that it breaks existing programs.
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 20:15 UTC (Fri) by khim (subscriber, #9252) [Link] that's a valid argument if the change improves something, but if (as in this case) the change doesn't give any performance improvement, the only 'advantage' of the change is that it breaks existing programs. Wow. Just… wow. I guess it's time to ask the usual question: are you an idiot or just play one on TV? You were given link - now, please go and read it. People tend to see message from Linus (which says I bothered to _measure_ the speed, and according to my measurements, glibc wasn't any faster than my trivial version and was likely slower) and immediately switch to Linus is god, GLibC developers are stupid mindset. Which is not justified at all. Because of course the very next sentence (but I only tested two cases) in the same paragraph flies right over their head and detailed explanation (At last on Core2 we gain 1.83x speedup compared with original instruction sequence and Based on our micro-benchmark small bytes from 1 to 127 bytes, we got up to 2X improvement, and up to 1.5X improvement for 1024 bytes on Corei7) is totally ignored or, at best, hand-waved with hopefully Linus has answered this one appeal to authority. This is the same never-ending fight between pragmatists and standard hairsplitters. Linus, ever the pragmatist, never rebuffed speedup claim when it was pointed out that he was incorrect (good for him: speedup is very much hardware-dependent and was just unobservable on the hardware he used, it's quite real and measurable on different hardware) but he said quite sensible thing from pragmatist's POV: new version of memcpy may be more efficient, but it's more complex as well thus the usual excuse (we have trivial and fast Note: GLibC guys rolled back change for old binaries pretty quickly when it was found that their improvement broke real programs. After that point it's no longer about “stable ABI” and “backward compatibility”, but about “doing the right thing”. I think the end result (old programs get the old behavior and new ones should finally fix the bugs in according to the documentation) makes sense in this context. You can say that this is what should have happened from the beginning, but it was not all that obvious that so many programs actually depend on the broken behavior of the old
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 20:17 UTC (Fri) by corbet (editor, #1) [Link] ...and that's my cue for the usual request: can we please be just a bit more respectful of each other? If you disagree then by all means say so and why. But we don't need to be playing elementary-school name-calling games here.
"does well to be conservative about adopting a solution"? Posted Apr 6, 2012 20:27 UTC (Fri) by paulj (subscriber, #341) [Link]
There should be a naughty chair for commentators who resort to name-calling. Maybe ½ to 1 hour of not being allowed to comment?
A turning point for GNU libc Posted Mar 31, 2012 21:35 UTC (Sat) by lacos (subscriber, #70616) [Link] truncation isn't silent: if (sizeof buf <= strlcpy(buf, str, sizeof buf)) oops("truncated!"); I don't like this. strlcpy() continues to find the end / length of the source string even if the target buffer has ended way earlier. And it does it every single time. Instead of this, know the length of your source string (which takes a single strlen() in the beginning), and allocate the target buffer accordingly. Or, if the target is a given, and too small, bail out before copying any characters.
|
|||||||||||||