> Florian Weimer wrote: > >> Robert C. Seacord wrote: >> >> i agree that the optimization is allowed by C99. i think this is a >> quality of implementation issue, and that it would be preferable for >> gcc to emphasize security over performance, as might be expected. > > I don't think this is reasonable. If you use GCC and its C frontend, > you want performance, not security. After all, the real issue is not > the missing comparison instruction, but the fact that this might lead to > subsequent unwanted code execution. ... > > The problem I see with this particular case is that the type of > comparison you describe is bogus even if translated to straight machine > code because it assumes an awful amount of detail about the target > environment. ...
No, (nor necessarily a question of "security over performance") but rather a question of whether any optimization should functionally change observable program behavior, which in general it should be clear it never should, as such schizophrenic optimizations will only tend to introduce inconsistent results, which regardless of their "legality", such optimizations most often provide no value to anyone. (as faster is better, but not at the expense of inconsistency; nor should optimizations be used to misguidedly intentionally break non-portable code, as non-portable code may still represent perfectly "legal" and useful programs, and is not the way to encourage the authoring of portable programs). Thereby clearly optimizations should be sensitive to the behavior of the target in the absents of such optimizations; if a target wraps arithmetic (as most if not all targets factually do, regardless of whether a language spec says they must) pretending that they don't when an observable behavior is known to be dependent on it, will only needlessly and unproductively introducing a functional bug (presuming the program behaved as intended in it's absents, regardless of the code's portability). Aggressive optimizations (particularly those which do not coincide with the factual behavior of most targets) should arguably only be invoked by explicit request (i.e. not at a generic level of optimization). IMHO. (as an aside, as most target implementations treat pointers as unsigned values, its not clear that presuming signed integer overflow semantics are a reasonable choice for pointer comparison optimization)
