> From: Michael Veksler <[EMAIL PROTECTED]>> >> Paul Schlie wrote on 20/06/2005 14:13:33: >>> From: Robert Dewar <[EMAIL PROTECTED]> > ... >>> Note that in the cases where something is statically optimized away >>> (these are the easy cases), it is nice if the compiler warns that this >>> is happening that would certainly be the case in Ada in the corresponding >>> situation, not sure about C++). But of course no such warning is required. >> >> Agreed. And given that the standard enables an implementation to do >> anything >> upon encountering an undefined behavior, it just seems just as correct to >> simply presume that the behavior will be consistent with the targets >> native >> behavior; as just because it may enable the compiler to do anything, it >> doesn't imply that it should, or that it would be a good idea to do so. >> > > Agreed in theory. Can you define "to do anything" ? What aspects > of the language can be defined as "native behavior"? What aspects > are always undefined? (e.g. uninitialized pointer dereference?). > > As for overflow, you can say that you want instead of "undefined" > to treat is "unspecified". Where each architecture / opsys / compiler > must consistently define what happens on overflow: > - saturation > - wrap 2's (or 1's) complement > - exception.
- yes, effectively I don't perceive any necessity for undefined, vs unspecified; as I don't perceive any necessity to give the compiler the freedom to treat generate an arbitrary program which may contain a potentially ambiguous specific and isolatable behavior. Again, is seems real simple to abide by C's sequence point and as-if rules to contain any ambiguity to the bounds between it's logical sequence points, and any resulting side-effects specific to that ambiguity must be expressed and logically bounded there. > You can argue (and maybe show benchmarks) that the above > "unspecified" does not inhibit too many real world optimizations, > as compared with "undefined". If that were the case, you would > have a chance convincing the std and gcc of your views. - can one show that it is unreasonable? > However, generalizing things for all "undefined behavior" is > doomed to failure. Not all "undefined behaviors" were born equal, > and you can't treat them as equal, unless they > "enable the compiler to do anything". - example? > You can be pragmatic, and try hard to minimize the cases where > the compiler happens "to do anything", but you cannot formally > guarantee that it will never happen. If you are not careful you may > end up with a spaghetti compiler full of special code geared > at the avoiding many of the "to do anything" cases. > > > Michael >
