Paul Schlie <[EMAIL PROTECTED]> wrote on 20/06/2005 16:09:16:
> > From: Michael Veksler <[EMAIL PROTECTED]>>
> > 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.
Look again at my dangling pointer example. In this example, the most
benign optimizations may "generate an arbitrary program" in this case.
As I said, and as Robert Dewar concurred, you can carefully define
something less strict than "undefined" on a case by case basis.
On the other hand, it is impossible to make all "undefined" cases
demonstrate an "isolatable behavior". Such a broad requirement is
impossible to fulfill, as my dangling pointer example shows.
>
> > 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?
Someone will have to prove it first. Just waving hands will
convince nobody. Maybe if you are lucky, you may convince
somebody to make an experiment, that in the end may or may
not lead to changes in gcc or the std.
>
> > 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?
Again, the dangling pointer example. Dangling pointer may or
may not lead to the corruption of the code itself (self modifying
code). When that inadvertently happens, all bets are off.
It is possible that by pure luck the code is "safe" without
optimization, and after optimizing unrelated stuff the
code becomes self destructive.
This is one of the cases of "undefined" behavior that cannot be
reasonably bounded. Would you like to sub-categorize
"undefined" to get rid of cases like the dangling pointer?
Are you willing to make sure that they are OK?
Again, this is a nontrivial task to get right. You can't get
it simply by disabling optimization X or fixing optimization Y.
This is out of the scope of this list. This list is not intended
to discuss and define new language semantics. You will have
to either come up with a reasonable definition yourself, or
get help from experts in the field. And only then go to the
std or gcc.
I have been burnt by these issues too many times exactly
because I am not an expert in the field, I am still learning.
You too should try to be more cautious in the treacherous
realm of language specification. Are you sure you want
to go there?
Michael
