pointer addresses

[Bill Cunningham]

From a previous thread I was corrected in my syntax. My tutorial
demonstrates the address of pointers and pointees. I don't know if it's the
address they hold or their virtual address as assigned by kernel services
under the hood. But here's corrected code and a warning from my compiler.

#include <stdio.h>

int main()
{
int *p;
int a = 15;
p = &a;
printf("%p\n", (void *) &a);
printf("%p\n", (void *) a);
}

Very simple. I believethis is what I was told is correct now for compiler
stderr output.

p.c: In function 'main':
p.c:9:20: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]

:Shrug:

 

[Lew Pitcher]

From a previous thread I was corrected in my syntax. My tutorial
demonstrates the address of pointers and pointees. I don't know if it's
the address they hold or their virtual address as assigned by kernel
services under the hood. But here's corrected code and a warning from my
compiler.

#include <stdio.h>

int main()
{
int *p;
int a = 15;
p = &a;
printf("%p\n", (void *) &a);
printf("%p\n", (void *) a);
}

Very simple. I believe this is what I was told is correct

No, Bill

now for compiler stderr output.
p.c: In function 'main':
p.c:9:20: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]

Yes, Bill

Take a look at the line
printf("%p\n", (void *) a);

What is "a"? Can it be a pointer?

Never mind the "(void *)". That's just you forcing the compiler to treat "a"
as a pointer to void. But, as I asked before, what is "a"? Is it a pointer
that can be cast to void *?

 

[John Gordon]

printf("%p\n", (void *) &a);

You're printing the address of a as a pointer. All well and good.

printf("%p\n", (void *) a);

You're printing the VALUE of a as a pointer. What the heck?!

 

[Bill Cunningham]

You're printing the address of a as a pointer. All well and good.


You're printing the VALUE of a as a pointer. What the heck?!

Sorry slight mistake! Change that to p. Here I changed it!

#include <stdio.h>

int main()
{
int *p;
int a = 15;
p = &a;
printf("%p\n", (void *) &p);
printf("%p\n", (void *) p);
}

Ok no errors. I notice each time I run this of course a different address is
given but in so many bytes of what a pointer is supposed to be from a
pointee.

Bill

 

[Bill Cunningham]

From a previous thread I was corrected in my syntax. My tutorial
demonstrates the address of pointers and pointees. I don't know if it's
the address they hold or their virtual address as assigned by kernel
services under the hood. But here's corrected code and a warning from my
compiler.

#include <stdio.h>

int main()
{
int *p;
int a = 15;
p = &a;
printf("%p\n", (void *) &a);
printf("%p\n", (void *) a);
}

Very simple. I believe this is what I was told is correct

No, Bill

now for compiler stderr output.
p.c: In function 'main':
p.c:9:20: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]

Yes, Bill

Take a look at the line
printf("%p\n", (void *) a);

What is "a"? Can it be a pointer?

Never mind the "(void *)". That's just you forcing the compiler to treat
"a"
as a pointer to void. But, as I asked before, what is "a"? Is it a pointer
that can be cast to void *?

Made a mistake Made a mistake! I do that sometimes! Check the new post.
Whew

 

[Bill Cunningham]

Never mind the "(void *)". That's just you forcing the compiler to treat
"a"
as a pointer to void. But, as I asked before, what is "a"? Is it a pointer
that can be cast to void *?

Sorry Lew that is of course supposed to be a p! Ok... Well that cast I
am told is the "proper" way to write this snippet of code. Now my tutorials
are showing a good example of something here though. With the right code and
using a p you see that there is exactly so much space between &p and p. The
pointee and the pointer. Somewhere in the machine is an address that
contains an int and the value 15.

Bill

 

[Barry Schwarz]

Ok no errors. I notice each time I run this of course a different address is
given but in so many bytes of what a pointer is supposed to be from a
pointee.

There is no "supposed to be" difference between two different scalar
objects or two objects not part of the same aggregate. Once the
program is compiled, the layout of the automatic variables is set. No
matter how many different times you run it, the two objects will
always be the same number of bytes apart.

What happens if you recompile the program with different options,
especially optimization differences? What happens if you throw in
another couple of variables? What happens if you reorder the
definition of the variables in your source code?

Given your problems with basic C concepts, this is an observation you
should be ignoring. Any program that depends on a particular
relationship between independent variables is plowing through
undefined behavior.

 

[Bill Cunningham]

Given your problems with basic C concepts, this is an observation you
should be ignoring. Any program that depends on a particular
relationship between independent variables is plowing through
undefined behavior.

Just noticing something my new book is telling me. And it IS right. And
you ADMITed it. Well that's just about how far I've gotten with it now.

Bill

 

[Bill Cunningham]

Given your problems with basic C concepts, this is an observation you
should be ignoring. Any program that depends on a particular
relationship between independent variables is plowing through
undefined behavior.

Now isn't that cast of a void * supposesd to prevent any "undefined
behavior"?

Bill

 

[Malcolm McLean]

Now isn't that cast of a void * supposesd to prevent any "undefined
behavior"?

Historically a lot of C code did cast between pointers and integers.
On most machines, addresses and integers are actually the same at
machine level. But not all. If a pointer is segmentffset, then it's
hard to say what casting an integer to a pointer is supposed to mean.

Some machines trap when an invalid address is loaded into an address
register. So declaring a void * with an invalid address could cause
the trap. Which leads to the question, if you're going to print out
the pointer, presumably something is wrong with it and you want to
examine it. So how do you do so, if the call to printf() is going to
trap?

 

[glen herrmannsfeldt]

(snip)

Historically a lot of C code did cast between pointers and integers.
On most machines, addresses and integers are actually the same at
machine level. But not all. If a pointer is segmentffset, then it's
hard to say what casting an integer to a pointer is supposed to mean.

For 16 bit x86, with segmentffset 16 bit each, and 16 bit int,
then assignment to int would get (I believe) only the offset.
You have to assign to 32 bit long to get segment and offset.

I am not sure about the Watcom compilers which also allowed
for large model 32 bit (16 bit segment selector, 32 bit offset).
As well as I remember, they didn't have a 64 bit (long long).

Some machines trap when an invalid address is loaded into an address
register. So declaring a void * with an invalid address could cause
the trap. Which leads to the question, if you're going to print out
the pointer, presumably something is wrong with it and you want to
examine it. So how do you do so, if the call to printf() is going to
trap?

If you have an illegal pointer in memory, you should be able to
copy it, for example with memcpy, to an array of unsigned char.

Note that JVM does not allow one to examine the bits of object
reference variables.

-- glen

 

[Tonton Th]

Ok no errors. I notice each time I run this of course a different address is
given but in so many bytes of what a pointer is supposed to be from a
pointee.

https://en.wikipedia.org/wiki/Address_space_layout_randomization

 

[Tonton Th]

With the right code and
using a p you see that there is exactly so much space between &p and p.

Thinking that it was that all the time is an human brain
undefined behavior.

 

[Anand Hariharan]

Very simple. I believethis is what I was told is correct now for compiler
stderr output.

p.c: In function 'main':
p.c:9:20: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]

:Shrug:

1/10

Not even the regs would think you're too stupid to see that you cant or
shouldnt cast a value such as "15" to a pointer value.

Up your game Bill.

To me, this was a dead give-away: https://groups.google.com/d/msg/comp.lang.c/ZcxjoD1R9rs/PyAjZROoVUAJ

He knows the cryptic name of the C standard (I assume it is the one that is current/latest?), he uses lmgtfy to be patronizing, and it is a response to Jacob who has a question about the rationale behind discrepancy between similar functions.

Certainly not from someone who has a learning impediment due to side-effects of medication.

- Anand

 

[Keith Thompson]

To me, this was a dead give-away:
https://groups.google.com/d/msg/comp.lang.c/ZcxjoD1R9rs/PyAjZROoVUAJ

He knows the cryptic name of the C standard (I assume it is the one
that is current/latest?), he uses lmgtfy to be patronizing, and it is
a response to Jacob who has a question about the rationale behind
discrepancy between similar functions.

Certainly not from someone who has a learning impediment due to
side-effects of medication.

That doesn't prove (or disprove) anything. Knowing about lmgtfy is
unremarkable. N1570 is the latest public draft of the C standard;
it's cited here on a regular basis. The response says nothing
about how well he understands the question jacob was asking --
except that the *rationale* for any such descrepancy is unlikely
to be found in the standard.

 

[Kaz Kylheku]

That doesn't prove (or disprove) anything.

Beyond a shadow of a doubt, like a mathematical theorem? No.

Anand has presented very strong evidence.

Knowing about lmgtfy is
unremarkable.

For a non-retard, yes.