Re: const and static (was: C vs. assembly...)

Given the example:


> > #define ONE 1
> > const int one = 1;
> >
> > int f()
> > {
> > x = ONE;
> > y = one;
> > }
>
> this should compile to exactly the same thing as the following does:
>
> int f() { x = 1; y = 1; }


King Dale <uunet!rnd1.indy.tce.com!KingD> writes:


> And if it does, you should quickly demand your money back for that
> compiler. Const does not mean that this variable is to be treated as a
> compile time constant. What it means is that the user of this
> definition cannot modify it. That doesn't mean some other routine won't.


This is simply not true. In fact, many compilers place const objects
in read only storage, and many environments will cause an exception if
any attempt is made to modify read only storage. Furthermore, some
compilers actually perform the optimization that is described in the
example above.


Before you "quickly demand your money back" though, you may want to
review section 3.5.3 of the ANSI C standard which states "If an
attempt is made to modify an object defined with a const-qualified
type through use of an lvalue with non-const-qualified type, the
behavior is undefined."


> Heck, C doesn't even care if you access it with a completely bogus type.


Again, this too is not true. You may want to review the text in
section 3.3 which begins "An object shall have its stored value
accessed only by an lvalue that has one of the following types: ...".
In particular, this section precludes such examples as accessing an
object of type int with a pointer to a short.


Recently, there was thread in comp.compilers regarding alias
optimizations that are permitted by ANSI C, and several compiler
developers expressed extreme reluctance to implement these alias
optimizations, citing that some programmers use, in your words,
"completely bogus types", with expectations that it will work, and
that these optimizations, although permitted by the standard, would
alter the behavior of these non-conforming programs. It is about your
programs that they are expressing such concerns.


Regards,
Christopher Glaeser cdg@nullstone.com
Nullstone Corporation http://www.nullstone.com
--

Return to the comp.compilers page.
Search the comp.compilers archives again.