Re: [PATCH] C undefined behavior fix

[Linus Torvalds <torvalds at transmeta dot com>]

On Fri, 4 Jan 2002, Richard Henderson wrote:
>
> On Fri, Jan 04, 2002 at 04:06:53PM -0800, Linus Torvalds wrote:
> > And it has to work (now, what _dereferencing_ the pointer does, that's
> > obviously a separate matter)
>
> Really?  You admit that?

I'm saying that the standard clearly says that _any_integer_ can be
converted into a pointer (with some implementation-defined conversion),
and that that part has to work.

The dereferencing has _other_ things that can cause it to be undefined (ie
it might not be properly aligned, it might not point to any object at all
etc etc). That's a separate issue.

> Then why are we having this conversation?  strcpy dereferences
> the pointer.

That STILL doesn't make it "undefined" - rather, it depends on what the
implementation-defined integer-to-pointer conversion end result ends up
being. It's just that the act of dereferencing a pointer has different
limitations than the act of creating the pointer in the first place.

The _creation_ of the pointer is defined regardless of what the conversion
function is and cannot cause undefined behaviour. But accessing a pointer
(regardless of _how_ it was created) that simply doesn't point anywhere
might or might not be well defined.

That's outside the scope of the C standard, although the standard actually
does say that "The mapping functions for converting a pointer to an
integer or an integer to a pointer are inteded to be consistent with the
addressing structure of the execution environment". Which is consistent
with the historical "bitwise" conversion, of course.

And is _very_ consistent with the notion that a program that knows what
the memory address space layout is may use these mappings to create
well-defined C functions that depend on (for example) knowing about
mapping aliases at certain offsets.

		Linus