This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: jtv <jtv at xs4all dot nl>
- To: dewar at gnat dot com
- Cc: jbuck at synopsys dot COM, gcc at gcc dot gnu dot org, linux-kernel at vger dot kernel dot org, linuxppc-dev at lists dot linuxppc dot org, paulus at samba dot org, trini at kernel dot crashing dot org, velco at fadata dot bg
- Date: Thu, 3 Jan 2002 01:32:40 +0100
- Subject: Re: [PATCH] C undefined behavior fix
- References: <20020103001241.E37DFF2EC6@nile.gnat.com>
On Wed, Jan 02, 2002 at 07:12:41PM -0500, dewar@gnat.com wrote:
>
> Note incidentally that the C rules that allow referencing the address just
> past the end of an array (an irregularity that recognizes the infeasibility
> of declaring the common idiom for (a=b;a<&b[10];a++)) has an interesting
> consequence on a segmented machine, namely that you cannot allocate an
> array too near the end of the segment.
At the risk of going off topic, you can take the non-element's address but
you can't actually touch it. So provided your architecture supports
pointer arithmetic beyond the end of the segment, your only remaining
worries are (1) that you don't stumble into the NULL address (which need
not be zero), and (2) that the address isn't reused as a valid element of
something else. I'm not so sure the latter is even a requirement.
Which does tie in to what we were discussing: in "foo"+LARGE_CONSTANT,
the problem is that C makes no promises on where "foo" ends up in memory,
or if it's even a single place, or what is located at any given offset
from it, or that the sum is even something that can be considered an
address in any way. Nor does the compiler need to assume that the
programmer knows better--bar some compiler-specific support for this
trick.
Jeroen
(Yes, I'm a pedant. I'm pining for the day when gcc will support the
options "-ffascist -Wanal")