Recent Features
| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 11, 2010 1:19 UTC (Thu) by tialaramex (subscriber, #21167)In reply to: Glibc change exposing bugs by nix Parent article: Glibc change exposing bugs
I think it /is/ C, but it isn't clear what the C means. This code doesn't break any of the rules of the C language which would cause it not to parse. Otherwise we wouldn't have got into this mess because it wouldn't compile.
[ Sadly I don't trust the Adobe developers enough to imagine that a diagnostic from static analysis would have stopped them doing this. I think "Warning: abuse of memcpy()" would have scrolled by with hundreds of other warnings they ignore... ]
In the same way "Don't frabidulate the wugs, she's my uncle" is an English sentence, but it isn't clear what it means. You can parse it, and you can answer some questions about it, e.g. "Are you being asked to frabidulate the wugs?" but there are big unknowns.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 11, 2010 7:21 UTC (Thu) by nix (subscriber, #2304) [Link] This code doesn't break any of the rules of the C language which would cause it not to parse.It is true that the standard does not require a diagnostic in this case, and that providing a diagnostic in all cases at compile time is impossible, but that doesn't make it any less 'not C'. C is not just 'what the compiler happens to accept'. (I completely agree that in this particular case a warning would likely have been useless unless accompanied by a brickbat.) btw, HJ's trying to fix the underlying problem here.
|
|||||||||||||