Re: type based aliasing again - meaning of "undefined"

[craig AT jcb-sc dot com]

>I'm still
>confused - if undefined behavior indicates an error, why does the standard
>indicate that one way of dealing with it is "in a documented manner
>characteristic of the environment (with or without the issuance of a
>diagnostic message)"?

Read the ISO C standard carefully.  If you can find that it says
that undefined behavior is an "error", and the way an implementation
must deal with an "error" is to do as you quote, then let us know...it'd
sure be news to me.

Rather, I suspect you just leaped to the conclusion that undefined
behavior == some concept the standard perhaps labeled "error", or
just with that phrase you quoted.  It's easy for that to happen,
due to confusing precise ways in which a specification uses a
term with typical uses of the term in normal speech.

So I don't think "undefined behavior" == "error" in ISO C, even
though we would all agree that invoking ISO-C-style undefined
behavior is an *erroneous* thing to do.

The whole point of the phrase "undefined behavior", or the word
"undefined" alone, in most standards I've dealt with is to
abruptly *end* any and all assurances the standard might offer
as to how a conforming implementation will behave as of that
point.

The hard thing to understand about this is that if you compile this
(I didn't, so ignore typos):

main()
{
  int i = 1;
  int j = 0;

  printf ("hello\n");
  foo (i, j);
  printf ("there\n");
  printf ("sailor\n");
}

foo(int i, int j)
{
  i = i / j;
  printf ("and ahoy\n");
}

Then you run it, and it prints:

hello
and ahoy
there
dr. dolittle

Then there is, despite surface appearances, *no* bug demonstrated in
the implementation (the compiler).

I've seen people (well, one person comes to mind) argue on comp.lang.fortran
until their posts were blue in the font that since the implementation
clearly continued executing the main program unit after foo() returned,
and since main(), by itself, was conforming, that the implementation
must be buggy, since it didn't execute main() in a conforming manner.

That's wrong, since, as of the division by zero, the standard stops saying
*anything* about what the implementation must or must not do.  That
means it does not even say "the implementation can do anything it wants,
except appear to continue executing the program, unless it appears to
execute it as expected until completion".

The reason?  "as expected" is meaningless except vis-a-vis "defined",
i.e. as defined by the standard.  If the standard "wanted" to define
how an implementation behaves after executing a divide-by-zero operation,
regardless of how imprecisely, then, by golly, it wouldn't say it was
"undefined".

By the way, the few brave souls who read my other huge email about
engineering and complexity will, in a few cases where they did not
already grok this, perhaps have a light go on in their heads: defining
things is, as an activity, one that *adds* complexity to a component,
in both its black-box and white-box senses.  Of course, the particulars
of what it defines might or might not reduce overall complexity of
any given system of which the component could be a part, depending
on whether the defined things help the system designer by reducing
the number of components he needs to use...but, generally, the more
a standard or specification leaves undefined, the simpler *it*, as
well as any component designed to implement that standard, is.

The point being that saying "wouldn't it be easier if ISO C simply
defined all these behaviors to mean something" implies being willing
to *add* complexity to the standard as well as to all compilers trying
to implement it.  (Amazingly enough, it also adds to the complexity
of the language as learned by humans, especially vis-a-vis code
written to it, but I haven't covered *that* topic in a long time,
and probably shouldn't go into it here, since it pertains to language
design, which I'd rather not encourage people to engage in on *this* list.)

        tq vm, (burley)