| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 10, 2010 21:20 UTC (Wed) by JoeBuck (subscriber, #2330)In reply to: Glibc change exposing bugs by jwb Parent article: Glibc change exposing bugs No, the semantics of the function are that the behavior is not defined if the source and destination strings overlap, as the relevant standards and the man page clearly state. That's why there's an alternative function named memmove. If you write C, call memcpy, and the arguments overlap, you've written a non-portable program.
(Log in to post comments)
Glibc change exposing bugs Posted Nov 10, 2010 21:55 UTC (Wed) by nix (subscriber, #2304) [Link]
Nah, it would be non-portable if it were implementation-defined whether memcpy() worked for overlapping regions. Since it is undefined, what you have written when you use a memcpy() on overlapping regions is technically (in the most pedantic mode imaginable) not C at all.
(I know you know this, this is really for others reading)
Glibc change exposing bugs Posted Nov 11, 2010 1:19 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
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.
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.
|
|||||||||||||