auto const ints and pointer issue

auto const ints and pointer issue

[Karen Shaeffer]

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 <stdio.h>

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 = &ic;
  ip = (int *)cip;
  *ip = 5;
  printf("const int ic = %d   *cip = %d   *ip = %d\n", ic, *cip, *ip);
  printf("&ic = %p    cip = %p    ip = %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 = 0xbfbd72a0    cip = 0xbfbd72a0    ip = 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
 shaeffer@neuralscape.com  http://www.neuralscape.com

Re: auto const ints and pointer issue

[Ian Lance Taylor]

Karen Shaeffer <shaeffer@neuralscape.com> writes:

> int main(int argc, char * argv[]) {
>   const int ic = 0;
>   const int * cip;
>   int * ip;
>   cip = &ic;
>   ip = (int *)cip;
>   *ip = 5;
>   printf("const int ic = %d   *cip = %d   *ip = %d\n", ic, *cip, *ip);
>   printf("&ic = %p    cip = %p    ip = %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 = 0xbfbd72a0    cip = 0xbfbd72a0    ip = 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

Re: auto const ints and pointer issue

[Karen Shaeffer]

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
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > 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
 shaeffer@neuralscape.com  http://www.neuralscape.com

Re[2]: auto const ints and pointer issue

[Dmitry I. Yanushkevich]

Hello Karen,

Tuesday, June 17, 2008, 10:38:20 PM, you wrote:

> 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 ;)

  I  don't  see  why the addresses are not correct. You should explore
  compiler's  assembler  output  to see what's really going there. But
  let us check the case here for now.

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 = %p    cip = %p    ip = %p\n", &ic, cip, ip);
}

  As  I  see this case, gcc just puts `const int ic` value in register
  (its ok since it is declared const and cannot be changed in runtime)
  (you  can even assume that it's reading it from its place in memory)
  and  that  value  from  the  register  gets  pushed on the stack for
  printf()  argument.  Of  course,  it  is  not modified by your later
  assignment because of compiler assumption that consts cannot change.
  If  you  consider that this way, there's no problem in what gcc does
  and what addresses/values are returned.


-- 
Best regards,
 Dmitry                            mailto:gauri@steelmonkeys.com

Re: auto const ints and pointer issue

[Andrew Haley]

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 = 0xbfbd72a0    cip = 0xbfbd72a0    ip = 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.

Re: auto const ints and pointer issue

[Karen Shaeffer]

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 = 0xbfbd72a0    cip = 0xbfbd72a0    ip = 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
 shaeffer@neuralscape.com  http://www.neuralscape.com

Re: auto const ints and pointer issue

[Karen Shaeffer]

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
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > 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
 shaeffer@neuralscape.com  http://www.neuralscape.com

Re: auto const ints and pointer issue

[Andrew Pinski]

On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer
<shaeffer@neuralscape.com> 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 = &ic;
 ip = (int *)cip;
 cip = ip;

And cip should be the same as &ic at the end of that code sequence.

Thanks,
Andrew Pinski

Re: auto const ints and pointer issue

[Karen Shaeffer]

On Tue, Jun 17, 2008 at 09:52:17PM -0400, Andrew Pinski wrote:
> On Tue, Jun 17, 2008 at 9:44 PM, Karen Shaeffer
> <shaeffer@neuralscape.com> 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 = &ic;
>  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
 shaeffer@neuralscape.com  http://www.neuralscape.com

Re: auto const ints and pointer issue

[Ian Lance Taylor]

Karen Shaeffer <shaeffer@neuralscape.com> writes:

> 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.

Undefined behaviour is undefined behaviour.  You can not predict what
the compiler do.  

> the value
> stored in that location cannot be 0 and 5 at the same time.

No, but in the presence of undefined behaviour the compiler is
perfectly free to assume that that is in fact the case.  This isn't
intentional, of course; it just falls out of other optimizations.

Ian

Re: auto const ints and pointer issue

[jlh]

Hi!

Karen Shaeffer wrote:
> 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.

Correct, and there aren't two values in that physical memory
location, there is only one value stored in there: the value 5.
(Assuming GCC 4.1.2 with -O2.)  At the time where the first
printf() is executed, the program won't even bother to go read
that memory location (which contains the value 5), because it
*knows* that it contains the value 0.  It knows it because you
promised that it contains the value 0 and that it will never ever
change.  So it won't even bother loading it and directly print the
value 0.  That's the result of an optimization: Not reading a
memory location when its content is already known makes your
program run faster; just use the known content instead.  But you
as the programmer have given GCC a promise that you broke later on
and thus the program behaves in an arguably unexpected way.  (It
*is* expected, since printing what it prints falls under the
definition of "undefined behavior.)

In fact, that memory location is never actually read.  When
printing *cip and *ip, the program simply prints 5, because it
knows there's the value 5 in that memory location, because it just
wrote it there.  Even the "ci = 0" is not storing to any memory
location, it has been optimized away.  All that remains is a
useless assignment of the value 5 into a memory location that is
never read again, and the resulting code:

    printf("const int ic = %d   *cip = %d   *ip = %d\n", 0, 5, 5);

However, if I compile with -O0 (no optimization), then the program
prints what you might have expected.

"Undefined behavior" means for you: Avoid it and don't expect the
compiler to try to do any sane thing when encountered or to reduce
damage to a minimum or to do the "expected" thing.  That would
even be impossible to do.  Just don't be undefined and you're
fine.

Oh, and looking at the assembly output (with "gcc file.c -S") is
often very helpful to see what's going on.

Hope this helps,
jlh

Re: auto const ints and pointer issue

[Joe Buck]

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.

Re: auto const ints and pointer issue

[Karen Shaeffer]

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
 shaeffer@neuralscape.com  http://www.neuralscape.com