auto const ints and pointer issue
Hi,
I have stumbled upon a quirk that appears to me to be
illogical. Maybe someone can help me to understand this:
sample code ~
#include
const int gic = 0;
const int * gcip;
int * gip;
int main(int argc, char * argv[]) {
const int ic = 0;
const int * cip;
int * ip;
cip =
ip = (int *)cip;
*ip = 5;
printf("const int ic = %d *cip = %d *ip = %d\n", ic, *cip, *ip);
printf("&ic = %pcip = %pip = %p\n", &ic, cip, ip);
gcip = &gic;
gip = (int *)gcip;
#if 0
*gip = 5;
printf("global const int gic = %d *gcip = %d *gip = %d\n",
gic, *gcip, *gip);
printf("&gic = %p gcip = %p gip = %p\n", &gic, gcip, gip);
#endif
return 0;
}
output ~~
$ const_ints
const int ic = 0 *cip = 5 *ip = 5
&ic = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0
~~~
The global variable code would segfault, as I expected. But the
auto variable code gives this illogical result. I would appreciate
comments. I am not on this list, so please ensure I am cc'd with
any responses. I'll be happy to file a bug, if it is a bug.
Thanks,
Karen
--
Karen Shaeffer
Neuralscape, Palo Alto, Ca. 94306
[EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
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 = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 > > ~~~ > > > > The global variable code would segfault, as I expected. But the > > auto variable code gives this illogical result. I would appreciate > > comments. I am not on this list, so please ensure I am cc'd with > > any responses. I'll be happy to file a bug, if it is a bug. > > Modifying a variable which is declared const is undefined behaviour. > You can not predict what happens. > > Ian Hi Ian, I can live with that. My problem was that the addresses cannot be correct. In my opinion, the undefined behavior should be limited to the value in the address or in some form of error. But to let the buggy code execute with addresses that are not accurate is a liberty I would hope could have been avoided. It just looks bad. I do realize, no one should have a gripe, because the code is buggy to begin with. But addresses should always be reported accurately IMHO. Of course, I obviously know nothing about compilers. (smiles ;) Thanks for your comments. Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
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 = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 > > ~~~ > > > > The global variable code would segfault, as I expected. But the > > auto variable code gives this illogical result. I would appreciate > > comments. I am not on this list, so please ensure I am cc'd with > > any responses. I'll be happy to file a bug, if it is a bug. > > Modifying a variable which is declared const is undefined behaviour. > You can not predict what happens. > > Ian Hi Ian, I can appreciate that. My point was the addresses are not valid here. 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. Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
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 = 0xbfbd72a0cip = 0xbfbd72a0ip = 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
Re: auto const ints and pointer issue
Hi, Hahaha! I know, I have been getting an education here. I really appreciate everyone's patience on this issue. I have assimilated all the excellent comments and understand my own laziness has caused my confusion. Thank you all. Karen On Wed, Jun 18, 2008 at 11:20:00AM +0100, Andrew Haley wrote: > Karen Shaeffer 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 = 0xbfbd72a0cip = 0xbfbd72a0ip = 0xbfbd72a0 > >>> ~~~ > >>> > >>> The global variable code would segfault, as I expected. But the > >>> auto variable code gives this illogical result. I would appreciate > >>> comments. I am not on this list, so please ensure I am cc'd with > >>> any responses. I'll be happy to file a bug, if it is a bug. > >> Modifying a variable which is declared const is undefined behaviour. > >> You can not predict what happens. > > > I can live with that. My problem was that the addresses cannot > > be correct. In my opinion, the undefined behavior should be > > limited to the value in the address or in some form of error. > > Your opinion about undefined behaviour is not shared by the C > Standard committee: undefined code may do anything. As the > saying goes, "Demons might fly our of your nose." > > > But to let the buggy code execute with addresses that are not > > accurate is a liberty I would hope could have been avoided. It > > just looks bad. I do realize, no one should have a gripe, because > > the code is buggy to begin with. But addresses should always be > > reported accurately IMHO. Of course, I obviously know nothing > > about compilers. (smiles ;) > > For what it's worth, this is a common misunderstanding. A proper > understanding of the true meaning of "undefined behaviour" comes > later. > > Andrew. ---end quoted text--- -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
Re: auto const ints and pointer issue
On Wed, Jun 18, 2008 at 09:41:26AM -0700, Joe Buck wrote: > On Tue, Jun 17, 2008 at 08:51:24PM -0700, Karen Shaeffer wrote: > > I see your point. My sticking point is that the process is actually > > running on a physical machine. > > And that's the problem. You, like many C programmers, have in your head a > physical machine model where pointer variables are physical machine > addresses and other variables are physical memory locations. But C > doesn't necessarily work that way (except at -O0); if it did, programs > would run substantially slower. The compiler can make optimizations (like > reusing values in registers) in certain circumstances. Anywhere in the > standard where you see that a behavior is undefined, read that as meaning, > the compiler is allowed to produce an arbitrary code sequence, so it will > produce the fastest, or smallest, or simplest-to-implement sequence. > > > 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. > > Right, but since it's const, the compiler is allowed to assume that it > is, well, const! That means that if it has already read the value into > a register, it can assume that the register is still valid for the > remainder of the program execution, even if you decide to violate the > rules of C and change the "constant". That's why it appears to be > 0 and 5 at the same time. > > To get rid of that behavior, you'd have to force the compiler to read > every variable from memory every time, and not use registers at all. Thanks Joe, Hahaha. Let's let this thread die. You haven't added anything new that hasn't already been discussed. It's turning into noise. Thanks, Karen -- Karen Shaeffer Neuralscape, Palo Alto, Ca. 94306 [EMAIL PROTECTED] http://www.neuralscape.com
