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

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

[Ross Morgan-Linial]

I've been watchin this discussion on the archives, and I'm a bit confused
about the meaning of "undefined" in the C9x standard, as you're using it.
The standard defines it as

       behavior, upon use of a  nonportable  or  erroneous  program
       construct,  of  erroneous data, or of indeterminately valued
       objects, for which this International  Standard  imposes  no
       requirement.

It seems to me that that says that a program that does something undefined
isn't necessarily wrong, just nonportable. Since previous versions of GCC
apparently behaved consistently when type aliasing requirements were
violated, why are programs that violate them considered erroneous? Or am I
misreading the standard?

    Ross

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

[craig]

>       behavior, upon use of a  nonportable  or  erroneous  program
>       construct,  of  erroneous data, or of indeterminately valued
>       objects, for which this International  Standard  imposes  no
>       requirement.
>
>It seems to me that that says that a program that does something undefined
>isn't necessarily wrong, just nonportable. Since previous versions of GCC
>apparently behaved consistently when type aliasing requirements were
>violated, why are programs that violate them considered erroneous? Or am I
>misreading the standard?

"imposes no requirement" presumably applies to the *implementation*,
i.e. the compiler, libraries, underlying machine, etc.

Therefore, the apparent consistent behavior which you cite is,
according to the standard, completely irrelevant to the behavior
of an implementation, since the programs that violate the standard
by invoking undefined behavior aren't so much "erroneous" as they
*specifically* grant the implementation the freedom to do whatever
the heck it wants -- including doing the same thing the first 10
million times that undefined behavior is invoked, then something
completely different (like "start World War 3") the next time.

        tq vm, (burley)

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

[Ross Morgan-Linial]

On 15 Sep 1999 craig@jcb-sc.com wrote:

> "imposes no requirement" presumably applies to the *implementation*,
> i.e. the compiler, libraries, underlying machine, etc.

Right.

> Therefore, the apparent consistent behavior which you cite is,
> according to the standard, completely irrelevant to the behavior
> of an implementation, since the programs that violate the standard
> by invoking undefined behavior aren't so much "erroneous" as they
> *specifically* grant the implementation the freedom to do whatever
> the heck it wants -- including doing the same thing the first 10
> million times that undefined behavior is invoked, then something
> completely different (like "start World War 3") the next time.

Sounds right (but why would anyone write a compiler that does that?). I
think it's interesting that the example the standard gives for undefined
behavior is integer overflow - imagine the uproar that would happen if you
changed *that*. I guess it's just not obvious to me that the results of
violating the type alias rules should be more like, say, dereferencing a
null pointer (which I expect to cause problems) than like casting a
pointer to an integer (which I usually expect to be consistent, if
undocumented).

    Ross

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

[craig]

>Sounds right (but why would anyone write a compiler that does that?). I
>think it's interesting that the example the standard gives for undefined
>behavior is integer overflow - imagine the uproar that would happen if you
>changed *that*. I guess it's just not obvious to me that the results of
>violating the type alias rules should be more like, say, dereferencing a
>null pointer (which I expect to cause problems) than like casting a
>pointer to an integer (which I usually expect to be consistent, if
>undocumented).

Immediately beyond the realm of what the standard defines lies the
land of "quality of implementation".  Beyond *that* land lies "buggy
user code".  Border disputes between those lands are common.  Border
disputes between defined and undefined lands occur, but the borders
themselves are usually pretty easy for people to spot.

It's mainly because the border between "undefined" and "defined" is
so much clearer than "reasonably-behaved according to the standard"
and "unreasonably-behaved such that it breaks code that most of us
think is pretty clear about what it wants to do, even though it is,
strictly speaking, undefined" that people who actually *work* on
compilers prefer the "undefined" border when it comes to making
long-term promises about how the compiler we maintain will or will
not behave.

The latter border just keeps moving all the time, so at no point
can a compiler developer *ever* even *think* (except in a state
of self-delusion) that he's going to perfect his product vis-a-vis
that border.  What to some people is "quality" is to other people
"broken", and vice versa.  Sometimes the very same people exhibit
two opinions within moments of each other.

Therefore, perfection in a compiler can be practically reached
only vis-a-vis defined vs. undefined behavior, plus reasonable
choices for implementation-defined behavior.  Anything beyond
that is an issue of "quality of implementation".  Of course,
on GCC, we rarely bother waiting on perfection before making forays
into quality-land, but, here, we're basically being asked to
maintain a military presence in broken-code land so the locals
will be able to pretend they're in quality land, on the basis that,
in the past, we hadn't actually dropped any missiles on that particular
corner of broken-code land.  That that corner of broken-code land thus
became infested with particularly large rats should *not* be our problem,
and we seem to be solving it already with this first missile, aka GCC 2.95
and its higher levels of optimization.

And it goes without saying that maintaining a military presence *two*
continents away, when one has not yet established supremacy in
the one in between, and one still has some flare-ups (aka bugs vis-a-vis
ISO C on at least some platforms) in ones' own land, is a *very* foolish
thing to try to do.  Promising one can do it amounts to knowingly
telling a lie, IMO.

        tq vm, (burley)

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

[craig]

>Sounds right (but why would anyone write a compiler that does that?). I
>think it's interesting that the example the standard gives for undefined
>behavior is integer overflow - imagine the uproar that would happen if you
>changed *that*. I guess it's just not obvious to me that the results of
>violating the type alias rules should be more like, say, dereferencing a
>null pointer (which I expect to cause problems) than like casting a
>pointer to an integer (which I usually expect to be consistent, if
>undocumented).

Immediately beyond the realm of what the standard defines lies the
land of "quality of implementation".  Beyond *that* land lies "buggy
user code".  Border disputes between those lands are common.  Border
disputes between defined and undefined lands occur, but the borders
themselves are usually pretty easy for people to spot.

It's mainly because the border between "undefined" and "defined" is
so much clearer than "reasonably-behaved according to the standard"
and "unreasonably-behaved such that it breaks code that most of us
think is pretty clear about what it wants to do, even though it is,
strictly speaking, undefined" that people who actually *work* on
compilers prefer the "undefined" border when it comes to making
long-term promises about how the compiler we maintain will or will
not behave.

The latter border just keeps moving all the time, so at no point
can a compiler developer *ever* even *think* (except in a state
of self-delusion) that he's going to perfect his product vis-a-vis
that border.  What to some people is "quality" is to other people
"broken", and vice versa.  Sometimes the very same people exhibit
two opinions within moments of each other.

Therefore, perfection in a compiler can be practically reached
only vis-a-vis defined vs. undefined behavior, plus reasonable
choices for implementation-defined behavior.  Anything beyond
that is an issue of "quality of implementation".  Of course,
on GCC, we rarely bother waiting on perfection before making forays
into quality-land, but, here, we're basically being asked to
maintain a military presence in broken-code land so the locals
will be able to pretend they're in quality land, on the basis that,
in the past, we hadn't actually dropped any missiles on that particular
corner of broken-code land.  That that corner of broken-code land thus
became infested with particularly large rats should *not* be our problem,
and we seem to be solving it already with this first missile, aka GCC 2.95
and its higher levels of optimization.

And it goes without saying that maintaining a military presence *two*
continents away, when one has not yet established supremacy in
the one in between, and one still has some flare-ups (aka bugs vis-a-vis
ISO C on at least some platforms) in ones' own land, is a *very* foolish
thing to try to do.  Promising one can do it amounts to knowingly
telling a lie, IMO.

        tq vm, (burley)

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

[Ross Morgan-Linial]

On 15 Sep 1999 craig@jcb-sc.com wrote:

> "imposes no requirement" presumably applies to the *implementation*,
> i.e. the compiler, libraries, underlying machine, etc.

Right.

> Therefore, the apparent consistent behavior which you cite is,
> according to the standard, completely irrelevant to the behavior
> of an implementation, since the programs that violate the standard
> by invoking undefined behavior aren't so much "erroneous" as they
> *specifically* grant the implementation the freedom to do whatever
> the heck it wants -- including doing the same thing the first 10
> million times that undefined behavior is invoked, then something
> completely different (like "start World War 3") the next time.

Sounds right (but why would anyone write a compiler that does that?). I
think it's interesting that the example the standard gives for undefined
behavior is integer overflow - imagine the uproar that would happen if you
changed *that*. I guess it's just not obvious to me that the results of
violating the type alias rules should be more like, say, dereferencing a
null pointer (which I expect to cause problems) than like casting a
pointer to an integer (which I usually expect to be consistent, if
undocumented).

    Ross

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

[Mark Mitchell]

    >> behavior, upon use of a nonportable or erroneous program
    >> construct, of erroneous data, or of indeterminately valued
    >> objects, for which this International Standard imposes no
    >> requirement.
    >> 
    >> It seems to me that that says that a program that does
    >> something undefined isn't necessarily wrong, just
    >> nonportable. Since previous versions of GCC apparently behaved
    >> consistently when type aliasing requirements were violated, why
    >> are programs that violate them considered erroneous? Or am I
    >> misreading the standard?

What you're missing is that there is a substantial qualitative
difference between "undefined" and "implementation-defined"; the
latter is a category of behavior for which implementations should do
reasonable things, while the first applies to truly erroneous
programs.

For exapmle, dereferencing NULL is "undefined behavior".  So is using
an uninitialized variable.  So is dividing by zero.  All things which
most C programmers would agree constitute bugs in their code.  Even a
high quality implementation will probably generate code that crashes
or behaves erratically when confronted with programs that have
undefined behavior.

Examples of implementation-defined behavior are whether bitfields are
signed are unsigned, how many bits are in an int, and how
floating-point calculations are rounded.  These are cases where the
compiler is *allowed* to choose ridiculous values (like `one million
bits in an int') without violating the standard, but that doesn't mean
any reasonable compiler should do it.  A high-quality implementation
should make reasonable choices for these behaviors, and document them.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Ross Morgan-Linial]

On Wed, 15 Sep 1999, Mark Mitchell wrote:

> What you're missing is that there is a substantial qualitative
> difference between "undefined" and "implementation-defined"; the
> latter is a category of behavior for which implementations should do
> reasonable things, while the first applies to truly erroneous
> programs.

Really?

       3.18
       [#1] undefined behavior
       ...
       [#3]  EXAMPLE  An  example  of undefined behavior is the
       behavior on integer overflow.

I've never considered integer overflow to indicate a truly erroneous
program.

    Ross

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

[craig]

>I've never considered integer overflow to indicate a truly erroneous
>program.

You can learn something every day.  Or, in my experience, every
few minutes by carefully reading the *standard* for pretty much any
language or library you *think* you know!!

        tq vm, (burley)

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

[Ross Morgan-Linial]

On 15 Sep 1999 craig@jcb-sc.com wrote:

> >I've never considered integer overflow to indicate a truly erroneous
> >program.
> 
> You can learn something every day.  Or, in my experience, every
> few minutes by carefully reading the *standard* for pretty much any
> language or library you *think* you know!!

You're right, I always assumed that integer overflow was
implementation-defined. In fact, it was mainly because that was the
example given that I wondered what "undefined" really means. 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)"? I'm not trying to suggest that the type alias
behavior should be treated this way.

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

[Mark Mitchell]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> You're right, I always assumed that integer overflow was
    Ross> implementation-defined. In fact, it was mainly because that
    Ross> was the example given that I wondered what "undefined"
    Ross> really means. I'm still confused - if undefined behavior
    Ross> indicates an error, why does the standard indicate that one
    Ross> way of dealing with it is "in a documented manner
    Ross> characteristic of the environment (with or without the
    Ross> issuance of a diagnostic message)"?

That's a nice thing to do, if you can.  So, for example, if you
misdeclare `main', the implementation can just issue an error
message.  If you misdeclare `main' in a way that's legal on your
system, you might get a warning, and things might work; the copmiler
could document that.

If you compiler is instead an interpreter, it can do run-time checks,
and then issue errors, ala Java.  The standard is trying to encourage
these kinds of alternatives.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Mark Mitchell]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> You're right, I always assumed that integer overflow was
    Ross> implementation-defined. In fact, it was mainly because that
    Ross> was the example given that I wondered what "undefined"
    Ross> really means. I'm still confused - if undefined behavior
    Ross> indicates an error, why does the standard indicate that one
    Ross> way of dealing with it is "in a documented manner
    Ross> characteristic of the environment (with or without the
    Ross> issuance of a diagnostic message)"?

That's a nice thing to do, if you can.  So, for example, if you
misdeclare `main', the implementation can just issue an error
message.  If you misdeclare `main' in a way that's legal on your
system, you might get a warning, and things might work; the copmiler
could document that.

If you compiler is instead an interpreter, it can do run-time checks,
and then issue errors, ala Java.  The standard is trying to encourage
these kinds of alternatives.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[craig]

>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)

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

[craig]

>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)

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

[Ross Morgan-Linial]

On 15 Sep 1999 craig@jcb-sc.com wrote:

> >I've never considered integer overflow to indicate a truly erroneous
> >program.
> 
> You can learn something every day.  Or, in my experience, every
> few minutes by carefully reading the *standard* for pretty much any
> language or library you *think* you know!!

You're right, I always assumed that integer overflow was
implementation-defined. In fact, it was mainly because that was the
example given that I wondered what "undefined" really means. 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)"? I'm not trying to suggest that the type alias
behavior should be treated this way.

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

[craig]

>I've never considered integer overflow to indicate a truly erroneous
>program.

You can learn something every day.  Or, in my experience, every
few minutes by carefully reading the *standard* for pretty much any
language or library you *think* you know!!

        tq vm, (burley)

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

[Mark Mitchell]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> On Wed, 15 Sep 1999, Mark Mitchell wrote:

    >> What you're missing is that there is a substantial qualitative
    >> difference between "undefined" and "implementation-defined";
    >> the latter is a category of behavior for which implementations
    >> should do reasonable things, while the first applies to truly
    >> erroneous programs.

    Ross> Really?

Yes, really.

    Ross>        3.18 [#1] undefined behavior ...  [#3] EXAMPLE An
    Ross> example of undefined behavior is the behavior on integer
    Ross> overflow.

    Ross> I've never considered integer overflow to indicate a truly
    Ross> erroneous program.

Two things:

  a) That's a mistake.  There have been machines that will trap on
     integer overflow.  (Of course, *unsigned* overflow is
     guaranteed by the standard; just not overflow of signed
     integers.  One historical reason is ones-complement machines;
     there are no longer many of those still running.)
     
     Also, compilers can generate "bad" code if you have integer
     overflow.  Consider, for example:

       int i;
       for (i = INT_MAX - 3; i < 0; ++i)
         {
	   if (f ())
	     break;
	 }
 
     It's sensible for the compiler to omit the loop test; it can
     never be true, since `i' starts positive and is only incremented.
     It's likely that GCC will implement this optimization, and/or
     related ones, in the future. Perhaps they'll be on by default,
     perhaps not; that's not my call to make.

     Even more subtle is that compilers can create "induction
     variables" when doing loop optimizations that are scaled
     differently than the original variables.  The correctness of
     these optimizations can depend on the signed-integers-do-not-overflow
     assumption.

  b) You're choosing to ignore other examples of undefined
     behavior, including the truly egregious ones I mentioned.  Here
     are some others:

       o Defining `main' without using either the `()' or `(int, char
         **)' type.

       o A line that ends in the middle of a string, like this:

           "abc
	    def"

       o Using reserved words as the names of identifiers.

       o Declaring something both `static' and `extern' at the same
         time.

       o Modifying a string literal.
 
       o Saying `x ^ y' where `x' and `y' are `float'.

       o Modifying a `const' object, e.g.:
       
           const int i = 3;
	   i = 7;

     These things are *extremely* non-portable at best.  Note that
     some (like the first) may work fine on some systems (like those
     that pass the environment as a third argument), but not at all
     on others.  Others, like the last, represent truly horrible 
     programming.  

     Note, by the way, that GCC does not *yet* take advantage of
     const-ness when doing alias analysis.  At some point in the
     future, it will.  There are programs that thought `const' was
     just a hint, to get better error-checking, and do things like:
     
       const int i = 3;
       int *ip = (int *)&i;
       *ip = 2;

     They often do this in C++ via calls to methods, so the RMS
     suggestion will not catch even the majority of the violations.
     These programs will break when we do the (extremely beneficial
     to conforming programs) optimization of assuming that `*ip'
     cannot modify `i'.  GCC will implement this optimization at 
     some point; whether it's on by default or not is again not
     my call.

     One of my concerns about the -fstrict-aliasing bit is exactly
     what will happen in the longer term when we do these other
     optimizations.  I expect they will break approximately as many
     programs as -fstrict-aliasing, and in similarly hard to track
     down ways.  Just like uninitialized variables are hard to track
     down.

     That's undefined behavior for you; programs that have undefined
     behavior are just plain destined to break in the long term.  And
     often the breakage will not be obvious.  That's why coding 
     carefully, and to the standard, is a good idea.  It's also why
     tools that help (including GCC, and including RMS's warning
     proposal) are a good thing.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Ross Morgan-Linial]

On Wed, 15 Sep 1999, Mark Mitchell wrote:

> >>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:
> 
>     Ross> Really?
> 
> Yes, really.

Okay, I believe you.

>      Also, compilers can generate "bad" code if you have integer
>      overflow.  Consider, for example:
> 
>        int i;
>        for (i = INT_MAX - 3; i < 0; ++i)
>          {
> 	   if (f ())
> 	     break;
> 	 }
>  
>      It's sensible for the compiler to omit the loop test; it can
>      never be true, since `i' starts positive and is only incremented.
>      It's likely that GCC will implement this optimization, and/or
>      related ones, in the future. Perhaps they'll be on by default,
>      perhaps not; that's not my call to make.

Gurk. You're right, overflow is icky. Somehow, I suspect that when that
change is made, programs will break. What about this code?

for (i = 0; some_condition(); i++) {
    if (i < 0) oops_we_overflowed();
    do_something();
}

Someone might actually use that somewhere(?).

>   b) You're choosing to ignore other examples of undefined
>      behavior, including the truly egregious ones I mentioned.  Here
>      are some others:
> 
>        o A line that ends in the middle of a string, like this:
> 
>            "abc
> 	    def"

Good example. :-)
Recently, in a newsgroup I read, someone complained that some code 
wouldn't compile, and the programmer faulted said person's compiler...

>      That's undefined behavior for you; programs that have undefined
>      behavior are just plain destined to break in the long term.  And
>      often the breakage will not be obvious.  That's why coding 
>      carefully, and to the standard, is a good idea.  It's also why
>      tools that help (including GCC, and including RMS's warning
>      proposal) are a good thing.

Agreed.

Question: would there be a problem with treating (where feasable)
undefined behavior that has had a consistent effect, that people actually
use, in the same way as deprecated features? That is, warn about them for
a few versions before going ahead and breaking them?

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

[Mark Mitchell]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> for (i = 0; some_condition(); i++) { if (i < 0)
    Ross> oops_we_overflowed(); do_something(); }

    Ross> Someone might actually use that somewhere(?).

Yup.  Someday, they'll find `oops_we_overflowed' is never called
because the compiler decided the conditional is always false.

    Ross> Question: would there be a problem with treating (where
    Ross> feasable) undefined behavior that has had a consistent
    Ross> effect, that people actually use, in the same way as
    Ross> deprecated features? That is, warn about them for a few
    Ross> versions before going ahead and breaking them?

Yes, that's a good idea, where feasible, both in terms of giving a
helpful warning and in terms of not taking undue effort to produce the
warning.

As I recall, we did half of this with -fstrict-aliasing; we had a
release where it was off by default, but available.  We didn't have a
warning, though.  I don't think anyone could figure out how to issue a
sensible warning; that's (one) of the things on the table right now.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Mark Mitchell]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> for (i = 0; some_condition(); i++) { if (i < 0)
    Ross> oops_we_overflowed(); do_something(); }

    Ross> Someone might actually use that somewhere(?).

Yup.  Someday, they'll find `oops_we_overflowed' is never called
because the compiler decided the conditional is always false.

    Ross> Question: would there be a problem with treating (where
    Ross> feasable) undefined behavior that has had a consistent
    Ross> effect, that people actually use, in the same way as
    Ross> deprecated features? That is, warn about them for a few
    Ross> versions before going ahead and breaking them?

Yes, that's a good idea, where feasible, both in terms of giving a
helpful warning and in terms of not taking undue effort to produce the
warning.

As I recall, we did half of this with -fstrict-aliasing; we had a
release where it was off by default, but available.  We didn't have a
warning, though.  I don't think anyone could figure out how to issue a
sensible warning; that's (one) of the things on the table right now.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Ross Morgan-Linial]

On Wed, 15 Sep 1999, Mark Mitchell wrote:

> >>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:
> 
>     Ross> Really?
> 
> Yes, really.

Okay, I believe you.

>      Also, compilers can generate "bad" code if you have integer
>      overflow.  Consider, for example:
> 
>        int i;
>        for (i = INT_MAX - 3; i < 0; ++i)
>          {
> 	   if (f ())
> 	     break;
> 	 }
>  
>      It's sensible for the compiler to omit the loop test; it can
>      never be true, since `i' starts positive and is only incremented.
>      It's likely that GCC will implement this optimization, and/or
>      related ones, in the future. Perhaps they'll be on by default,
>      perhaps not; that's not my call to make.

Gurk. You're right, overflow is icky. Somehow, I suspect that when that
change is made, programs will break. What about this code?

for (i = 0; some_condition(); i++) {
    if (i < 0) oops_we_overflowed();
    do_something();
}

Someone might actually use that somewhere(?).

>   b) You're choosing to ignore other examples of undefined
>      behavior, including the truly egregious ones I mentioned.  Here
>      are some others:
> 
>        o A line that ends in the middle of a string, like this:
> 
>            "abc
> 	    def"

Good example. :-)
Recently, in a newsgroup I read, someone complained that some code 
wouldn't compile, and the programmer faulted said person's compiler...

>      That's undefined behavior for you; programs that have undefined
>      behavior are just plain destined to break in the long term.  And
>      often the breakage will not be obvious.  That's why coding 
>      carefully, and to the standard, is a good idea.  It's also why
>      tools that help (including GCC, and including RMS's warning
>      proposal) are a good thing.

Agreed.

Question: would there be a problem with treating (where feasable)
undefined behavior that has had a consistent effect, that people actually
use, in the same way as deprecated features? That is, warn about them for
a few versions before going ahead and breaking them?

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

[Michael Meissner]

On Wed, Sep 15, 1999 at 03:49:54PM -0700, Mark Mitchell wrote:
>      Note, by the way, that GCC does not *yet* take advantage of
>      const-ness when doing alias analysis.  At some point in the
>      future, it will.  There are programs that thought `const' was
>      just a hint, to get better error-checking, and do things like:
>      
>        const int i = 3;
>        int *ip = (int *)&i;
>        *ip = 2;
> 

Also note the rules for ANSI C are different from ANSI C++ in terms of const.
For example, I recall the following:

	int i;
	*(int *)(const int *)&i = 1;

is legit under ISO C.  IIRC, this is explicitly mentioned in one of the TC's (I
was still a member of the committee when TC.1 came out).

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

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

[Mark Mitchell]

>>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:

    Michael> Also note the rules for ANSI C are different from ANSI
    Michael> C++ in terms of const.  

I'm not aware of that, but it's possible.

    Michael> For example, I recall the following:

    Michael> 	int i; *(int *)(const int *)&i = 1;

    Michael> is legit under ISO C.  IIRC, this is explicitly mentioned
    Michael> in one of the TC's (I was still a member of the committee
    Michael> when TC.1 came out).

This is legal C++ as well.  It's the `const'-ness of the underlying
object that matters, just as with the alias issues it's the type of
thing actually pointed to that matters.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Mark Mitchell]

>>>>> "Michael" == Michael Meissner <meissner@cygnus.com> writes:

    Michael> Also note the rules for ANSI C are different from ANSI
    Michael> C++ in terms of const.  

I'm not aware of that, but it's possible.

    Michael> For example, I recall the following:

    Michael> 	int i; *(int *)(const int *)&i = 1;

    Michael> is legit under ISO C.  IIRC, this is explicitly mentioned
    Michael> in one of the TC's (I was still a member of the committee
    Michael> when TC.1 came out).

This is legal C++ as well.  It's the `const'-ness of the underlying
object that matters, just as with the alias issues it's the type of
thing actually pointed to that matters.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Ross Smith]

Michael Meissner wrote:
> 
> Also note the rules for ANSI C are different from ANSI C++ in terms of const.
> For example, I recall the following:
> 
>         int i;
>         *(int *)(const int *)&i = 1;
> 
> is legit under ISO C.  IIRC, this is explicitly mentioned in one of the TC's (I
> was still a member of the committee when TC.1 came out).

It's legit under C++ too; see section 7.1.5.1 of the standard. Modifying
an object through a pointer or reference to const (by casting away the
const) is undefined only if the pointed-to object was actually declared
const:

    int var(1);
    const int con(2);
    const int* cp1(&var);
    const int* cp2(&con);
    *const_cast<int*>(cp1) = 3; // OK, object is not really const
    *const_cast<int*>(cp2) = 4; // Undefined, object is really const

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  "There are many technical details that make Linux attractive to the
  sort of people to whom technical details are attractive."   -- Suck

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

[Ross Smith]

Michael Meissner wrote:
> 
> Also note the rules for ANSI C are different from ANSI C++ in terms of const.
> For example, I recall the following:
> 
>         int i;
>         *(int *)(const int *)&i = 1;
> 
> is legit under ISO C.  IIRC, this is explicitly mentioned in one of the TC's (I
> was still a member of the committee when TC.1 came out).

It's legit under C++ too; see section 7.1.5.1 of the standard. Modifying
an object through a pointer or reference to const (by casting away the
const) is undefined only if the pointed-to object was actually declared
const:

    int var(1);
    const int con(2);
    const int* cp1(&var);
    const int* cp2(&con);
    *const_cast<int*>(cp1) = 3; // OK, object is not really const
    *const_cast<int*>(cp2) = 4; // Undefined, object is really const

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  "There are many technical details that make Linux attractive to the
  sort of people to whom technical details are attractive."   -- Suck

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

[Michael Meissner]

On Wed, Sep 15, 1999 at 03:49:54PM -0700, Mark Mitchell wrote:
>      Note, by the way, that GCC does not *yet* take advantage of
>      const-ness when doing alias analysis.  At some point in the
>      future, it will.  There are programs that thought `const' was
>      just a hint, to get better error-checking, and do things like:
>      
>        const int i = 3;
>        int *ip = (int *)&i;
>        *ip = 2;
> 

Also note the rules for ANSI C are different from ANSI C++ in terms of const.
For example, I recall the following:

	int i;
	*(int *)(const int *)&i = 1;

is legit under ISO C.  IIRC, this is explicitly mentioned in one of the TC's (I
was still a member of the committee when TC.1 came out).

-- 
Michael Meissner, Cygnus Solutions
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886
email: meissner@cygnus.com	phone: 978-486-9304	fax: 978-692-4482

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

[Marc Espie]

In article < 19990915154954O.mitchell@codesourcery.com > you write:
>
>     Note, by the way, that GCC does not *yet* take advantage of
>     const-ness when doing alias analysis.  At some point in the
>     future, it will.  There are programs that thought `const' was
>     just a hint, to get better error-checking, and do things like:
>     
>       const int i = 3;
>       int *ip = (int *)&i;
>       *ip = 2;
>
>     They often do this in C++ via calls to methods, so the RMS
>     suggestion will not catch even the majority of the violations.
>     These programs will break when we do the (extremely beneficial
>     to conforming programs) optimization of assuming that `*ip'
>     cannot modify `i'.  GCC will implement this optimization at 
>     some point; whether it's on by default or not is again not
>     my call.

Err... how are you going to deal with the `logical constness' idiom ?
I think it's been with C++ forever, and is thoroughly documented in
about all source books, including Stroustrup.

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

[Alexandre Oliva]

On Sep 16, 1999, Marc Espie <espie@quatramaran.ens.fr> wrote:

> In article < 19990915154954O.mitchell@codesourcery.com > you write:

>> const int i = 3;
>> int *ip = (int *)&i;
>> *ip = 2;

>> These programs will break when we do the (extremely beneficial
>> to conforming programs) optimization of assuming that `*ip'
>> cannot modify `i'.

> how are you going to deal with the `logical constness' idiom ?

Note that `i' is an actual const, not just a logical const, in this
program.  If you just had a pointer to const int, and you couldn't
tell whether it is just logically constant, you wouldn't be able to
perform this optimization.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

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

[Alexandre Oliva]

On Sep 16, 1999, Marc Espie <espie@quatramaran.ens.fr> wrote:

> In article < 19990915154954O.mitchell@codesourcery.com > you write:

>> const int i = 3;
>> int *ip = (int *)&i;
>> *ip = 2;

>> These programs will break when we do the (extremely beneficial
>> to conforming programs) optimization of assuming that `*ip'
>> cannot modify `i'.

> how are you going to deal with the `logical constness' idiom ?

Note that `i' is an actual const, not just a logical const, in this
program.  If you just had a pointer to const int, and you couldn't
tell whether it is just logically constant, you wouldn't be able to
perform this optimization.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

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

[Mark Mitchell]

>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:

    Marc> Err... how are you going to deal with the `logical
    Marc> constness' idiom ?  I think it's been with C++ forever, and
    Marc> is thoroughly documented in about all source books,
    Marc> including Stroustrup.

There, the underlying object is not const.  For example:

  struct S {
    int i;

    void f() const;
  } s;

  void S::f () const
  {
    (const_cast<S*> (this))->i = 3;
  }

  s.f();

is OK because the pointed-to object (`s') is not const. 

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Mark Mitchell]

>>>>> "Marc" == Marc Espie <espie@quatramaran.ens.fr> writes:

    Marc> Err... how are you going to deal with the `logical
    Marc> constness' idiom ?  I think it's been with C++ forever, and
    Marc> is thoroughly documented in about all source books,
    Marc> including Stroustrup.

There, the underlying object is not const.  For example:

  struct S {
    int i;

    void f() const;
  } s;

  void S::f () const
  {
    (const_cast<S*> (this))->i = 3;
  }

  s.f();

is OK because the pointed-to object (`s') is not const. 

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Marc Espie]

In article < 19990915154954O.mitchell@codesourcery.com > you write:
>
>     Note, by the way, that GCC does not *yet* take advantage of
>     const-ness when doing alias analysis.  At some point in the
>     future, it will.  There are programs that thought `const' was
>     just a hint, to get better error-checking, and do things like:
>     
>       const int i = 3;
>       int *ip = (int *)&i;
>       *ip = 2;
>
>     They often do this in C++ via calls to methods, so the RMS
>     suggestion will not catch even the majority of the violations.
>     These programs will break when we do the (extremely beneficial
>     to conforming programs) optimization of assuming that `*ip'
>     cannot modify `i'.  GCC will implement this optimization at 
>     some point; whether it's on by default or not is again not
>     my call.

Err... how are you going to deal with the `logical constness' idiom ?
I think it's been with C++ forever, and is thoroughly documented in
about all source books, including Stroustrup.

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

[Mark Mitchell]

>>>>> "Ross" == Ross Morgan-Linial <rmorgan@jetcity.com> writes:

    Ross> On Wed, 15 Sep 1999, Mark Mitchell wrote:

    >> What you're missing is that there is a substantial qualitative
    >> difference between "undefined" and "implementation-defined";
    >> the latter is a category of behavior for which implementations
    >> should do reasonable things, while the first applies to truly
    >> erroneous programs.

    Ross> Really?

Yes, really.

    Ross>        3.18 [#1] undefined behavior ...  [#3] EXAMPLE An
    Ross> example of undefined behavior is the behavior on integer
    Ross> overflow.

    Ross> I've never considered integer overflow to indicate a truly
    Ross> erroneous program.

Two things:

  a) That's a mistake.  There have been machines that will trap on
     integer overflow.  (Of course, *unsigned* overflow is
     guaranteed by the standard; just not overflow of signed
     integers.  One historical reason is ones-complement machines;
     there are no longer many of those still running.)
     
     Also, compilers can generate "bad" code if you have integer
     overflow.  Consider, for example:

       int i;
       for (i = INT_MAX - 3; i < 0; ++i)
         {
	   if (f ())
	     break;
	 }
 
     It's sensible for the compiler to omit the loop test; it can
     never be true, since `i' starts positive and is only incremented.
     It's likely that GCC will implement this optimization, and/or
     related ones, in the future. Perhaps they'll be on by default,
     perhaps not; that's not my call to make.

     Even more subtle is that compilers can create "induction
     variables" when doing loop optimizations that are scaled
     differently than the original variables.  The correctness of
     these optimizations can depend on the signed-integers-do-not-overflow
     assumption.

  b) You're choosing to ignore other examples of undefined
     behavior, including the truly egregious ones I mentioned.  Here
     are some others:

       o Defining `main' without using either the `()' or `(int, char
         **)' type.

       o A line that ends in the middle of a string, like this:

           "abc
	    def"

       o Using reserved words as the names of identifiers.

       o Declaring something both `static' and `extern' at the same
         time.

       o Modifying a string literal.
 
       o Saying `x ^ y' where `x' and `y' are `float'.

       o Modifying a `const' object, e.g.:
       
           const int i = 3;
	   i = 7;

     These things are *extremely* non-portable at best.  Note that
     some (like the first) may work fine on some systems (like those
     that pass the environment as a third argument), but not at all
     on others.  Others, like the last, represent truly horrible 
     programming.  

     Note, by the way, that GCC does not *yet* take advantage of
     const-ness when doing alias analysis.  At some point in the
     future, it will.  There are programs that thought `const' was
     just a hint, to get better error-checking, and do things like:
     
       const int i = 3;
       int *ip = (int *)&i;
       *ip = 2;

     They often do this in C++ via calls to methods, so the RMS
     suggestion will not catch even the majority of the violations.
     These programs will break when we do the (extremely beneficial
     to conforming programs) optimization of assuming that `*ip'
     cannot modify `i'.  GCC will implement this optimization at 
     some point; whether it's on by default or not is again not
     my call.

     One of my concerns about the -fstrict-aliasing bit is exactly
     what will happen in the longer term when we do these other
     optimizations.  I expect they will break approximately as many
     programs as -fstrict-aliasing, and in similarly hard to track
     down ways.  Just like uninitialized variables are hard to track
     down.

     That's undefined behavior for you; programs that have undefined
     behavior are just plain destined to break in the long term.  And
     often the breakage will not be obvious.  That's why coding 
     carefully, and to the standard, is a good idea.  It's also why
     tools that help (including GCC, and including RMS's warning
     proposal) are a good thing.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[Ross Morgan-Linial]

On Wed, 15 Sep 1999, Mark Mitchell wrote:

> What you're missing is that there is a substantial qualitative
> difference between "undefined" and "implementation-defined"; the
> latter is a category of behavior for which implementations should do
> reasonable things, while the first applies to truly erroneous
> programs.

Really?

       3.18
       [#1] undefined behavior
       ...
       [#3]  EXAMPLE  An  example  of undefined behavior is the
       behavior on integer overflow.

I've never considered integer overflow to indicate a truly erroneous
program.

    Ross

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

[Mark Mitchell]

    >> behavior, upon use of a nonportable or erroneous program
    >> construct, of erroneous data, or of indeterminately valued
    >> objects, for which this International Standard imposes no
    >> requirement.
    >> 
    >> It seems to me that that says that a program that does
    >> something undefined isn't necessarily wrong, just
    >> nonportable. Since previous versions of GCC apparently behaved
    >> consistently when type aliasing requirements were violated, why
    >> are programs that violate them considered erroneous? Or am I
    >> misreading the standard?

What you're missing is that there is a substantial qualitative
difference between "undefined" and "implementation-defined"; the
latter is a category of behavior for which implementations should do
reasonable things, while the first applies to truly erroneous
programs.

For exapmle, dereferencing NULL is "undefined behavior".  So is using
an uninitialized variable.  So is dividing by zero.  All things which
most C programmers would agree constitute bugs in their code.  Even a
high quality implementation will probably generate code that crashes
or behaves erratically when confronted with programs that have
undefined behavior.

Examples of implementation-defined behavior are whether bitfields are
signed are unsigned, how many bits are in an int, and how
floating-point calculations are rounded.  These are cases where the
compiler is *allowed* to choose ridiculous values (like `one million
bits in an int') without violating the standard, but that doesn't mean
any reasonable compiler should do it.  A high-quality implementation
should make reasonable choices for these behaviors, and document them.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

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

[craig]

>       behavior, upon use of a  nonportable  or  erroneous  program
>       construct,  of  erroneous data, or of indeterminately valued
>       objects, for which this International  Standard  imposes  no
>       requirement.
>
>It seems to me that that says that a program that does something undefined
>isn't necessarily wrong, just nonportable. Since previous versions of GCC
>apparently behaved consistently when type aliasing requirements were
>violated, why are programs that violate them considered erroneous? Or am I
>misreading the standard?

"imposes no requirement" presumably applies to the *implementation*,
i.e. the compiler, libraries, underlying machine, etc.

Therefore, the apparent consistent behavior which you cite is,
according to the standard, completely irrelevant to the behavior
of an implementation, since the programs that violate the standard
by invoking undefined behavior aren't so much "erroneous" as they
*specifically* grant the implementation the freedom to do whatever
the heck it wants -- including doing the same thing the first 10
million times that undefined behavior is invoked, then something
completely different (like "start World War 3") the next time.

        tq vm, (burley)

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

[David Edelsohn]

	I, personally, have been using "undefined" in the colloquial
sense, not as in the C standard.  We are arguing that behavior which is
implementation-dependent allows the compiler as much lattitude as it cares
to use.

	One line of reasoning is that if the compiler can behave the way
we have implemented and by doing that it produces better optimized code,
then that should be the default behavior.  Only non-conforming code which
depends upon implementation-dependent behavior is broken, so users should
be required to tell the compiler that the source code is non-conforming
explicitly. 

	The further argument is that if we bend on the default behavior
for this implementation-defined case, then we will be forced to treat any
change in compiler behavior this way and never add any additional default
optimizations.  This latter argument is based on conjecture, not fact.

David

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

[David Edelsohn]

	I, personally, have been using "undefined" in the colloquial
sense, not as in the C standard.  We are arguing that behavior which is
implementation-dependent allows the compiler as much lattitude as it cares
to use.

	One line of reasoning is that if the compiler can behave the way
we have implemented and by doing that it produces better optimized code,
then that should be the default behavior.  Only non-conforming code which
depends upon implementation-dependent behavior is broken, so users should
be required to tell the compiler that the source code is non-conforming
explicitly. 

	The further argument is that if we bend on the default behavior
for this implementation-defined case, then we will be forced to treat any
change in compiler behavior this way and never add any additional default
optimizations.  This latter argument is based on conjecture, not fact.

David

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

[Ross Morgan-Linial]

I've been watchin this discussion on the archives, and I'm a bit confused
about the meaning of "undefined" in the C9x standard, as you're using it.
The standard defines it as

       behavior, upon use of a  nonportable  or  erroneous  program
       construct,  of  erroneous data, or of indeterminately valued
       objects, for which this International  Standard  imposes  no
       requirement.

It seems to me that that says that a program that does something undefined
isn't necessarily wrong, just nonportable. Since previous versions of GCC
apparently behaved consistently when type aliasing requirements were
violated, why are programs that violate them considered erroneous? Or am I
misreading the standard?

    Ross

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

[Mike Stump]

> Date: Wed, 15 Sep 1999 19:52:06 -0400
> From: Michael Meissner <meissner@cygnus.com>

> Also note the rules for ANSI C are different from ANSI C++ in terms
> of const.  For example, I recall the following:

> 	int i;
> 	*(int *)(const int *)&i = 1;

> is legit under ISO C.  IIRC, this is explicitly mentioned in one of
> the TC's (I was still a member of the committee when TC.1 came out).

C++ and C are about the same, and once C puts in multi-level const
handling, they will be the same.  You can do the above in C++ as well,
this isn't a difference between the languages.

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

[Mike Stump]

> Date: Wed, 15 Sep 1999 19:52:06 -0400
> From: Michael Meissner <meissner@cygnus.com>

> Also note the rules for ANSI C are different from ANSI C++ in terms
> of const.  For example, I recall the following:

> 	int i;
> 	*(int *)(const int *)&i = 1;

> is legit under ISO C.  IIRC, this is explicitly mentioned in one of
> the TC's (I was still a member of the committee when TC.1 came out).

C++ and C are about the same, and once C puts in multi-level const
handling, they will be the same.  You can do the above in C++ as well,
this isn't a difference between the languages.

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

[N8TM]

In a message dated 9/15/99 4:08:42 PM EST, rmorgan@jetcity.com writes:

> Since previous versions of GCC
>  apparently behaved consistently when type aliasing requirements were
>  violated, why are programs that violate them considered erroneous? 
Because they depend on the compiler not performing useful optimizations which 
the standard specifically encourages.

Tim

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

[N8TM]

In a message dated 9/15/99 4:08:42 PM EST, rmorgan@jetcity.com writes:

> Since previous versions of GCC
>  apparently behaved consistently when type aliasing requirements were
>  violated, why are programs that violate them considered erroneous? 
Because they depend on the compiler not performing useful optimizations which 
the standard specifically encourages.

Tim

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

[David_Abrahams]

*quick delurkification*

It seems to me that an issue that ought to be of concern, but nobody is
      discussing is this: the compiler will at best be able to warn of a subset
      of aliasing violations.

Mark Mitchell <mark@codesourcery.com> wrote:
>If you compiler is instead an interpreter, it can do run-time checks,
>and then issue errors, ala Java.  The standard is trying to encourage
>these kinds of alternatives.

This is clearly the only way to find all aliasing violations, and that's
_assuming_ interpreted code could be sufficiently exercised.

Isn't anyone worried that users will expect (particularly if they see some
warnings) that if they clear up the warnings their code will work? I don't have
a position on the issue, but I worry about checks which seem to promise more
than they actually do, especially when the target audience includes "naive
users".

Handling this sort of issue in C++ is easy enough, in some sense: you can tell
people to avoid casts (and they usually are avoidable), then go and inspect the
dangerous areas by finding the few casts that are left. Not so easy with
existing bodies of 'C' code :(

-Dave

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

[David_Abrahams]

*quick delurkification*

It seems to me that an issue that ought to be of concern, but nobody is
      discussing is this: the compiler will at best be able to warn of a subset
      of aliasing violations.

Mark Mitchell <mark@codesourcery.com> wrote:
>If you compiler is instead an interpreter, it can do run-time checks,
>and then issue errors, ala Java.  The standard is trying to encourage
>these kinds of alternatives.

This is clearly the only way to find all aliasing violations, and that's
_assuming_ interpreted code could be sufficiently exercised.

Isn't anyone worried that users will expect (particularly if they see some
warnings) that if they clear up the warnings their code will work? I don't have
a position on the issue, but I worry about checks which seem to promise more
than they actually do, especially when the target audience includes "naive
users".

Handling this sort of issue in C++ is easy enough, in some sense: you can tell
people to avoid casts (and they usually are avoidable), then go and inspect the
dangerous areas by finding the few casts that are left. Not so easy with
existing bodies of 'C' code :(

-Dave