This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 05 Jan 2002 15:03:00 +0200
- Subject: Re: [PATCH] C undefined behavior fix
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <20020105005711.15A6FF28C4@nile.gnat.com> <"dewar@gnat.com"> <200201050103.RAA14079@atrus.synopsys.com>
jbuck@synopsys.COM (Joe Buck) wrote on 04.01.02 in <200201050103.RAA14079@atrus.synopsys.com>:
> > I thought the documentatoin was pretty clear, the rule about not misusing
> > integer arithmetic bla-bla seemed clearly stated to me, is that not part
> > of the documentation, or have I misunderstood?
>
> It is mathematically inconsistent with the sections that precede it. If
> you define I2P, and you define P2I, and you define PLUS, you have defined
> I2P(PLUS(P2I(p),i)), because at no point is an illegal or undefined
> expression created.
That is not the problem.
The problem is that some people expect that these operations would somehow
cause gcc to forget what the original pointer was, and it doesn't.
The problem is that whatever comes out of that computation, *when used as
a pointer*, is only valid for accessing the same object that went into the
computation in the first place.
That has absolutely *nothing* to do with any promises about keeping bits
the same when converting between pointers and integers. This is about an
attribute of a pointer that is *not* expressed in bits.
If you just put the constructed pointer in a variable, and then use one of
a dozen different ways of looking at the bits, you'll see that they are
exactly as promised.
Frankly, as long as you lie to gcc about where in memory your program bits
are, you deserve whatever you get. There's no reason to assume this is
*ever* possible.
MfG Kai