Re: [PATCH] C undefined behavior fix

[Linus Torvalds <torvalds at transmeta dot com>]

On Sat, 5 Jan 2002, Richard Henderson wrote:
>
> On Sat, Jan 05, 2002 at 11:17:52AM -0800, Linus Torvalds wrote:
> > Can you limit it down enough to be useful, then?
>
> What do you mean by that?

Basically, if you say that any pointer to an object that the compiler
knows about cannot be converted to an integer and back without you
hollering, is there maybe some set of this (or other approach) that you
_can_ guarantee?

As it is, your interpretation basically means that the bitwise
pointer/integer conversions are totally _useless_, because you can always
say that whatever we do with those conversions is undefined behaviour.

That's not useful implementation-defined behaviour.

> At present we don't have a mechanism to tell the compiler that
> it really doesn't understand what's going on here, despite the
> seeming simplicity of the PLUS.

May I suggest that a non-same-type cast just sever the ties to the pointer
representation? Which would certainly follow the letter _and_ the spirit
of the standard, ie you get the obvious and well-defined - but not as
optimizable - behaviour for accesses through pointer casts, while you can
do all the optimizations you like on "normal" code.

Absolutely NOBODY writes code like

	*(int *)((unsigned long) a + x) = y;

unless they are doing something that definitely knows too much about the
addressing on that machine. And if they do, they can't really complain
about the fact that the compiler didn't dare to optimize something around
the access and didn't do full alias analysis.

Now, that information is gone at the RTL level, but just adding some kind
of "alias barrier" whenever the compiler sees a integer/pointer cast would
certainly fix it. (Might be as simple as just a flag on the expression
that tells the alias logic to not follow the RTL further or something).

Let's face it - this issue has come up before, and will probably come up
again. People are using pointer tricks in C, not just in the kernel. Í
guarantee you that if there is a simple "out" that you can describe to
people and document, you won't have to field the issue every once in a
while.

The inline asm has the problem that it's not an expression, and thus ends
up being syntactically quite ugly (I thought gcc people didn't like
statement expressions, but that would definitely be forced upon people if
that's the only "out").

Also, the inline asm is not in the spirit supported by any C standard.
While I doubt anybody can claim that the C standard would frown upon the
implementation defined notion that a integer/pointer conversion might
alias with anything.

(It would also make the documentation issue really simple: you just
document the integer->pointer cast as a bitwise copy, and you never have
to worry about object borders etc simply because none of the logic that
matters would see past the cast).

			Linus