From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jamie Lokier <egcs@tantalophile.demon.co.uk>
To: dewar@gnat.com
Cc: schwab@suse.de, aoliva@redhat.com, denisc@overta.ru, dkorn@pixelpower.com, gcc@gcc.gnu.org, peter.osterlund@mailbox.swipnet.se
Subject: Re: Bug in loop optimize (invalid postinc to preinc transformation)
Date: Wed, 03 Jan 2001 00:52:00 -0000
Message-id: <20010103095147.A2594@thefinal.cern.ch>
References: <20001231163045.5B3B534D81@nile.gnat.com>
X-SW-Source: 2001-01/msg00110.html

dewar@gnat.com wrote:
> Indeed. The important thing to remember in C is that the semantic
> model of a pointer is a pair (pointer-to-object, offset). Address
> arithmetic just modifies the offset, comparison compares only the
> offsets (and is undefined if the pointer-to-object values are
> different).
> 
> Of course in practice the implementation is typically a single pointer
> from a flat space, representing the sum of the two components, but the
> proper semantic model needs to be kept in mind, and code that does not
> respect this semantic model has undefined effects.

The point (no pun intended) is that the problematic example code
includes a constant-valued pointer (unsigned char *) 0xffffffff.  Such a
pointer does not refer to any object unless your semantic model is a
flat space, in which all objects are sub-objects of a single "all of
memory" object.

> As C compilers get more clever, they are likely to be less permissive
> to abuses of the semantics :-)

Indeed.  As with strict type aliasing, as the compilers get more clever,
the programmers need clear definitions of which semantics they may rely
on from a particular compiler.  Many, many programs have a small part
that depends on traditional behaviour that's not defined in the ISO
standard.

-- Jamie