|
|
Subscribe / Log in / New account

Glibc change exposing bugs

Glibc change exposing bugs

Posted Nov 10, 2010 23:56 UTC (Wed) by nix (subscriber, #2304)
In reply to: Glibc change exposing bugs by lmb
Parent article: Glibc change exposing bugs

The code happened to work on Linux. It certainly wouldn't have worked on a lot of other OSes, even Unixes. It's undefined behaviour: it might be broken at any time, without warning. And now it has. Compiler optimizations could perfectly well have broken it instead: perhaps we should compile everything -O0 to remove the chance of that.

Emitting a warning to the logs is far too expensive: this stuff is so often called that the compiler sometimes open-codes it! Adding a conditional in there that isn't absolutely needed would have horrible effects on performance.

(And as for detecting it at compile time, well, sure! It requires whole-program optimization of every single program and all its shared libraries, and even then detecting it reliably reduces to solving the halting problem. This seems to be rather harder than just valgrinding the bloody thing and learning elementary C before you write it.)

(Sure, there will be actual bugs teased out by this: code that didn't expect to receive overlapping regions when it was written, but that now is. But, guess what? I bet those overlapping copies were causing other bugs, because it is surely rare for code to just memcpy() from region A to *unexpectedly*-overlapping region B and then never do anything with A again.)


to post comments


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds