4 ms·

Undefined behaviour was always there to make possible compilers to optimize as they like (nowadays usually for speed or to ease porting to specific architecture

by szemet 9y ago

Undefined behaviour was always there to make possible compilers to optimize as they like (nowadays usually for speed or to ease porting to specific architectures) - that is the essence of C "portable assembly" mentality and it always was. Am I wrong? I tolally agree that this is a bad mentality for software developement in general, but at least it is the "authentic C way" so I feel that part of the critics ungrounded...

deleted 9y ago
[deleted]
xorblurb 9y ago
Nope. The age of the sufficiently "advanced" (actually: retarded?) compiler was only theoretical during most of the lifetime of C, and UB were actually defined mostly because of differences between processors, NOT compilers. Compilers were faster thanks to their backend. The standard even says: "undefined behavior: behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements" However, today, you should act as if the nonportable part of this statement don't exist anymore, and act as if ALL UB are absolutely forbidden and result in the worst non-deterministic consequences, in all cases and regardless of your actual target. Meaning that today on e.g. x86, if you use a mainstream compiler, you ARE limited by some of the limitations of e.g. some obscure outdated DSPs. And this is likely impossible to check in a non-trivial program. So just use another language. C for serious purposes is dead. (some projects that started in that language continue to be developed in it, but given the security issues it creates, this will become unacceptable in a not too far future; so don't wait it is too late to switch: lead that movement.)
wfunction 9y ago
I don't think this is true, though I think it's a common misconception. Undefined behavior is not meant to be an optimization tool. It's meant to be an anti-pessimization tool. In other words, it's meant to eliminate overhead in cases where the programmer knows it is unnecessary, but which the compiler cannot prove. Eliminating overhead is conceptually very different from actively allowing insane behavior just to increase optimization opportunities.

by szemet 9y ago

deleted 9y ago

[deleted]

xorblurb 9y ago

Nope. The age of the sufficiently "advanced" (actually: retarded?) compiler was only theoretical during most of the lifetime of C, and UB were actually defined mostly because of differences between processors, NOT compilers. Compilers were faster thanks to their backend. The standard even says: "undefined behavior: behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements" However, today, you should act as if the nonportable part of this statement don't exist anymore, and act as if ALL UB are absolutely forbidden and result in the worst non-deterministic consequences, in all cases and regardless of your actual target. Meaning that today on e.g. x86, if you use a mainstream compiler, you ARE limited by some of the limitations of e.g. some obscure outdated DSPs. And this is likely impossible to check in a non-trivial program. So just use another language. C for serious purposes is dead. (some projects that started in that language continue to be developed in it, but given the security issues it creates, this will become unacceptable in a not too far future; so don't wait it is too late to switch: lead that movement.)

wfunction 9y ago

I don't think this is true, though I think it's a common misconception. Undefined behavior is not meant to be an optimization tool. It's meant to be an anti-pessimization tool. In other words, it's meant to eliminate overhead in cases where the programmer knows it is unnecessary, but which the compiler cannot prove. Eliminating overhead is conceptually very different from actively allowing insane behavior just to increase optimization opportunities.