Re: [PATCH] C undefined behavior fix

[mike stump <mrs at windriver dot com>]

> To: mike stump <mrs@windriver.com>
> cc: rth@redhat.com, gcc@gcc.gnu.org, paulus@samba.org, torvalds@transmeta.com
> Date: Sun, 06 Jan 2002 16:38:03 -0800
> From: Dennis Ferguson <dennis@juniper.net>

> > Your message doesn't indicate an understanding of the problem yet.

> Perhaps.  It may also be that we're talking about slightly different
> problems.

Ah, yes, good catch.  You appear to be referring to the doc, I was
referring to the original C code that showed a `bug'.

> > > Date: Sat, 05 Jan 2002 09:55:50 -0800
> > > From: Dennis Ferguson <dennis@juniper.net>
> 
> I sometimes have to write code which depends on
> implementation-defined behaviour.  I've been told that the code I
> write "should be safe", but I'm wondering why there isn't a way to
> change "should" to "will" and why the only way to find out what
> should work seems to be to send mail to this list.  The
> documentation above says to me that even if something works now it
> is not guaranteed to work in future, and that if my code stops
> working with some future revision of the compiler then I have only
> myself to blame since the documentation for the implementation's
> behaviour says what I do just happens to work.  What I want is
> documentation of what I can do, i.e. what you'll endeavor to keep
> working in future revisions of the compiler, so I can write code in
> future without having to ask here if it is okay.

Gee, such a language doesn't exist as far as I know, or if they do,
they are toy languages that aren't used.  The reality is that langauge
standards change the meaning of programs from time to time, so you
start out screwed.  From there, you venture into those things that are
documented in the manual that say they will never change, but do at
some point, and then you venture down into the things that we claim
won't change, but do... and so on.  I see it as just a continuum.
Maybe I'm just a cynic.  Should be safe sound like a phrase that came
from someone that shares a certain amount of cynicism.

We endeavor to keep things in the standards working, we endeavor to
keep things that are in the documented working, we endeavor to keep
things that are sane and reasonable working...

A crystal ball, or a really good expert `knows' which constructs will
change, which ones won't and how long they will be good for.

> > Use volatile if you want.  Use any construct for which you can inform
> > the compiler that it doesn't know.  Casting isn't such an operation,
> > as we have seen.

> So where is this written down?  The documentation seems to say you
> can't rely on doing this at all.

Any expansive text on volatile will cover it.  We can see some of the
bits of it from a C c99 working draft:

       [#2] An object whose identifier is declared with external or
       internal linkage, or with the storage-class specifier static
       has static storage duration.  For such an object, storage is
       reserved  and  its  stored  value  is initialized only once,
       prior to program startup.  The object exists, has a constant
       address,  and  retains  its last-stored value throughout the
       execution of the entire program.24

       24. [ ... ]

           In the case of a volatile object, the last store may not
           be explicit in the program.

[ ... ]

       [#6] An object  that  has  volatile-qualified  type  may  be
       modified in ways unknown to the implementation or have other
       unknown side effects.

[ ... ]

       99. A volatile declaration may be used to describe an object
           corresponding to a memory-mapped input/output port or an
           object  accessed  by  an   asynchronously   interrupting
           function.   Actions  on objects so declared shall not be
           ``optimized out''  by  an  implementation  or  reordered
           except   as   permitted  by  the  rules  for  evaluating
           expressions.

>From a draft of the C++ standard:

6 The observable behavior of the abstract machine  is  its  sequence  of
  reads   and   writes  to  volatile  data  and  calls  to  library  I/O
  functions.4)

[ ... ]

7 [Note:  volatile is a hint to the implementation to  avoid  aggressive
  optimization  involving  the  object  because  the value of the object
  might be changed by means undetectable by an implementation.  See  1.8
  for  detailed  semantics.   In general, the semantics of  volatile are
  intended to be the same in C++ as they are in C.  ]


Fairly clearly worded to me.  Do you not find the same meaning that I
do?

> > Nowhere in the code was the compiler informed of this, if you
> > disagree, point to it, tell us.  What we will tell you, is that the
> > compiler _must_ be informed about such things.

> Sure, but the documentation for the compiler makes the incantation
> needed to inform the compiler of this, and the conditions under
> which it is needed, an ambiguous and potentially moving target.

That is right, running code not at the right address is a ambiguous
and potentially moving target.  However, using volatile to inform the
compiler that it doesn't know what a value means is portable and
standard.  To the extent one needs to do this, using the construct to
do this is portable.  It is unfortunate that we're talking about
multiple things simultaneously, as the more complex ones obscure the
simplicity of the simpler ones.  In my text, I was talking about the
single aspect of hiding values from the compiler.

> As far as the documented implementation-defined behaviour of the
> compiler is concerned this "just happens to work" just like any
> pointer-to-integer-to-pointer conversions which involve manipulating
> the integer.

> So if volatile is the way to do this that you'll endeavor to keep
> working in future revisions of the compiler, could the above
> documentation be changed to say this?

I think the meaning of volatile is clear from the language standard.
We generally don't repeat aspects of the language standard in our
text.

For other aspects, I don't want to discuss them in this thread.  Too
confusing.  One thread, one bug, one aspect.