On Tue, Jun 17, 2008 at 09:52:17PM -0400, Andrew Pinski wrote: > On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer > <[EMAIL PROTECTED]> wrote: > > On Tue, Jun 17, 2008 at 11:01:31AM -0700, Ian Lance Taylor wrote: > >> > ~~~~~~~~~~~~~~~~ output ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> > $ const_ints > >> > const int ic = 0 *cip = 5 *ip = 5 > >> > &ic = 0xbfbd72a0 cip = 0xbfbd72a0 ip = 0xbfbd72a0 > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> > In my opinion, it seems reasonable to limit the undefined > > behavior to the value of the variable, or to some form of > > failure and error, up to and including crashing the process. > > But to implement the code in such a way to let the process > > proceed without error, and to have incorrect addresses as we > > see here, seems to be beyond the common sense scope of the bounds > > of what this assignment's undefined behavior potential effects > > might be. It is interesting. Thank you for your comment. > > I don't see the issue with the pointers being the same. I don't see > what you are asking to be different. Casting from one pointer type to > another is ok. So we can go from: > cip = ⁣ > ip = (int *)cip; > cip = ip; > > And cip should be the same as &ic at the end of that code sequence. > > Thanks, > Andrew Pinski
Hi Andrew, I see your point. My sticking point is that the process is actually running on a physical machine. And the addresses, although virtual, do translate to a unique physical memory location. And, the value stored in that location cannot be 0 and 5 at the same time. And my comments were addressing that the undefined behavior of this illegal assignment should not violate the physical constraints of what is actually stored in that physical address. I would be OK with -1 being stored in there, or zero, or whatever, or the process crashing, but what I see is not congruent with my thinking about the limits of the compiled binary at run-time. Obviously I need to rethink those assumptions. Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
