Re: [PATCH] C undefined behavior fix

[Dennis Ferguson <dennis at juniper dot 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.

> > Date: Sat, 05 Jan 2002 09:55:50 -0800
> > From: Dennis Ferguson <dennis@juniper.net>
> 
> > If we're talking about the more general case of converting pointers
> > to an integer representation of their bits, doing math on that, and
> > converting the result back to a pointer, then both device drivers
> > and memory allocators often depend on being able to do that fairly
> > freely.  The math isn't limited to addition and subtraction either,
> > paged memory allocators tend to also like to do multiplies and
> > divides (or, at least, shifts and masks).
> 
> This isn't the problem at hand.

Isn't it?  While it might be ambiguous in context, I'm actually addressing
what the documentation says.  The gcc documentation for implementation-defined
behaviour which was referenced to show that the problem at hand was the
programmer's problem says this:

    When casting from pointer to integer and back again, the resulting
    pointer must reference the same object as the original pointer, otherwise
    the behavior is undefined. That is, one may not use integer arithmetic
    to avoid the undefined behavior of pointer arithmetic as proscribed in
    6.5.6/8. 

Now I understand that the problem with the current compiler is limited
to pointers to a few very particular types of objects, but the documentation
for the compiler's behaviour above makes no distinction like this at all.
That is, I don't think there is a reading of the above which makes
operations on pointers to those particular types of objects undefined
which doesn't make the same operations on pointers to pretty much any object
undefined.  It makes no mention of any particular characteristics of the
object.

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.

> > But while it doesn't fix anything, what it does do is force me to
> > replace a single piece of C code which will work just fine on a
> > dozen different processors with a dozen assembly versions doing the
> > same computations.
> 
> 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.

> It is the users responsibility to inform the compiler what it is
> doing.  The case at hand is the case of moving the entire string pool
> around in memory, and then using it at a different address than where
> the compiler knew the string pool would be.
> 
> 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.
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?  Or, if this is too constraining
for future development, could something else which you'll try to keep
working be invented and documented?  I'd like my code to stay working,
and I'm willing to write the C code (i.e. not assembly) any way you say
I should to achieve this, but no one seems willing to tell me what to
do with enough conviction to actually write it down.

Does this make my problem clearer?

Thanks,
Dennis Ferguson