This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] C undefined behavior fix


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]