Steve M. Robbins wrote: > On September 21, 2013 09:04:23 PM Bernhard R. Link wrote: > > The whole point of undefined behaviour in C is that the > > compiler/implementor/... does not have to care. > > I strongly suspect the "whole point" of undefined behaviour is simply that at > least two parties on the committee simply couldn't agree on "correct" > behaviour.
You're completely wrong. It's not like there would be multiple plausible ways to define a fixed result in this case; the choice is between requiring the implementation to handle this special case or not, and they chose to not require it. And in cases where there's a plausible choice of "correct" behavior, implementation-defined behavior makes a lot more sense than undefined behavior. > > Checking every time would > > make it slower, > > What are you referring to as "it"? The compiler? Checking that two > arguments > to a function are the same doesn't strike me as terribly expensive. The compiler could issue a diagnostic if it can detect that the values of two arguments are the same, and this would detect some of the obvious cases mentioned earlier in the thread. But in general it's not possible to detect this without adding extra runtime checks. For example, if the program has a function my_sprintf that in turn calls sprintf, the compiler can't warn about the call to sprintf in my_sprintf since the validity of that depends on what arguments my_sprintf is called with, and it can't warn about calls to my_sprintf since it doesn't know those should avoid giving the same argument twice (at least unless some kind of global whole-program optimization is used that allows the compiler to see all the code at once). > > requesting any specific behaviour would make it slower. > > Nonsense -- it has a specific behaviour now. It does not have specific behavior now. You shouldn't assume that every possible undocumented implementation detail in some versions of a library is specified behavior that will keep working the same way forever. > Since the standard says it is > undefined, there's nothing stopping us from reverting back to its old > behaviour > which, arguably, better mached people's expectations -- else they wouldn't > have written the "buggy" code. Moreover, it is the same behaviour used when > NOT compiled with _FORTIFY_SOURCE=2. "else they wouldn't have written the buggy code" is a poor argument - people write lots of buggy code based on completely nonsensical assumptions and expectations. Trying to keep the buggy code silently working is the worst choice, and will just worsen the situation. Any attempts to keep it working should at least ensure there is a visible diagnostic, to prevent the creation of more such bugs and give a chance to fix the existing ones. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1379860280.23075.24.camel@glyph.nonexistent.invalid
