Memory address "value"

[mdh]

Quick question about pointers.
Wrote this "trying to understand this better" code:

int *ptr, x = 565;

ptr= &x;

printf("\n\n\nT he value of x is %d\n", x);
printf("Now: ptr= &x\n So:");
printf("The value of *ptr is %d\n", *ptr);
printf("And, straight ptr should give an address of \"x\"\n ");
printf("Ptr points at x whose address is is %d\n", ptr); /*<<<<<<<<
returns -1073743224<<<*/
return 0;
}
All except the last line work...or is the memory location indeed
"-1073743224"

Thanks in advance.

[John Gordon]

In <11************ **********@h48g 2000cwc.googleg roups.com"mdh" <md**@comcast.n etwrites:

printf("Ptr points at x whose address is is %d\n", ptr); /*<<<<<<<<

All except the last line work...or is the memory location indeed
"-1073743224"

When you use %d, you're telling printf that it's printing an integer.
But you did not supply an integer argument; you used a pointer instead,
which Ain't The Same Thing.

Use %p to print pointer values. (But only void pointers, so you'll
have to cast to void first.)

--
John Gordon "... What with you being his parents and all,
go****@panix.co m I think that you could be trusted not to shaft
him." -- Robert Chang, rec.games.board

[Kenneth Brody]

mdh wrote:

>
Quick question about pointers.

Wrote this "trying to understand this better" code:

int *ptr, x = 565;

ptr= &x;

[...]

printf("Ptr points at x whose address is is %d\n", ptr); /*<<<<<<<<
returns -1073743224<<<*/

[...]

All except the last line work...or is the memory location indeed
"-1073743224"

It could be.

First, "%d" expects an int, and you have pased an int*, so all bets
are off. However, given that your post says you're on an Intel Mac,
and most of those systems probably have sizeof(int)==si zeof(int*)==4,
it's probably sort-of okay on your platform.

Next, "%d" interprets the value as a signed integer, which makes for
strange interpretations for half of the address space.

Finally, -1073743224 decimal is 0xBFFFFA88 hex (assuming a 32-bit
signed int), which is certainly a reasonable address, especially if
the particular implementation starts the stack growing down from
0xC0000000.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Frederick Gotham]

mdh:

int *ptr, x = 565;

ptr= &x;

While we're saving space, we may aswell write:

int x = 565, *ptr = &x;

This also saves us mixing declarations with statements.

--

Frederick Gotham

[Martin Ambuhl]

mdh wrote:

Quick question about pointers.
Wrote this "trying to understand this better" code:

int *ptr, x = 565;
ptr= &x;

[...]

printf("Ptr points at x whose address is is %d\n", ptr); /*<<<<<<<<
returns -1073743224<<<*/

The specifier for a pointer is %p and its corresponding argument is a
void *:
printf("Ptr points at x whose address is %p\n",
(void *) ptr);

[Keith Thompson]

Kenneth Brody <ke******@spamc op.netwrites:
[...]

First, "%d" expects an int, and you have pased an int*, so all bets
are off. However, given that your post says you're on an Intel Mac,
and most of those systems probably have sizeof(int)==si zeof(int*)==4,

.... *and* pointer and integer arguments are probably passed using the
same mechanism ...p

it's probably sort-of okay on your platform.

Right. On some platforms, though, integer and pointer arguments can
be passed using different mechanisms, so the location that printf()
looks at in response to a "%d" format might have nothing at all to do
with the pointer value that you passed to it. (For example, the 68k
has separate integer and pointer CPU registers; I don't know whether
parameter passing mechanisms typically take advantage of this.)

If something is "probably sort-of okay on your platform", that's
usually a sign that you should fix it so it's "certainly for-sure okay
on all platforms". (That's not always possible, but it is in this
case.)

(I'm just emphasizing the point here, not disagreeing with anything
Kenneth wrote.)

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Walter Roberson]

In article <ln************ @nuthaus.mib.or g>,
Keith Thompson <ks***@mib.orgw rote:

>Right. On some platforms, though, integer and pointer arguments can
be passed using different mechanisms, so the location that printf()
looks at in response to a "%d" format might have nothing at all to do
with the pointer value that you passed to it. (For example, the 68k
has separate integer and pointer CPU registers; I don't know whether
parameter passing mechanisms typically take advantage of this.)

That would depend upon the ABI for that implementation. Some do,
some don't.
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Kenneth Brody]

Keith Thompson wrote:

>
Kenneth Brody <ke******@spamc op.netwrites:
[...]

First, "%d" expects an int, and you have pased an int*, so all bets
are off. However, given that your post says you're on an Intel Mac,
and most of those systems probably have sizeof(int)==si zeof(int*)==4,

... *and* pointer and integer arguments are probably passed using the
same mechanism ...p

it's probably sort-of okay on your platform.

Right. On some platforms, though, integer and pointer arguments can
be passed using different mechanisms, so the location that printf()
looks at in response to a "%d" format might have nothing at all to do
with the pointer value that you passed to it. (For example, the 68k
has separate integer and pointer CPU registers; I don't know whether
parameter passing mechanisms typically take advantage of this.)

I know of at least one 68K platform that _returns_ pointers in a
different place than numbers. If the function returns a pointer,
it uses the A0 register. Otherwise, it uses the D0 register. This
is a perfect example of why "I'll just cast the return of malloc()
to the right type to shut up that stupid warning" is a bad idea.
If you haven't included the proper header, and the compiler assumes
that malloc() returns int by default, it will look at D0 rather than
A0 for the return value, and get total garbage.

Now, this particular platform used the "normal" stack method of
passing parameters. However, I have seen platforms that pass the
first few parameters in registers (though there is only one set of
registers on those platforms), so it's certainly possible that there
is a platform which has more than one set of registers, and that
uses the registers to pass parameters, which would use different
registers depending on whether the parameter is a pointer or not.

If something is "probably sort-of okay on your platform", that's
usually a sign that you should fix it so it's "certainly for-sure okay
on all platforms". (That's not always possible, but it is in this
case.)

True.

(I'm just emphasizing the point here, not disagreeing with anything
Kenneth wrote.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>

[Random832]

2006-11-15 <45************ ***@spamcop.net >,
Kenneth Brody wrote:

Now, this particular platform used the "normal" stack method of
passing parameters. However, I have seen platforms that pass the
first few parameters in registers (though there is only one set of
registers on those platforms), so it's certainly possible that there
is a platform which has more than one set of registers, and that
uses the registers to pass parameters, which would use different
registers depending on whether the parameter is a pointer or not.

Even for platforms that do this, it seems unlikely they'd do it for
variadic functions. There's a reason they need a prototype in scope.

[Kenneth Brody]

Random832 wrote:

>
2006-11-15 <45************ ***@spamcop.net >,
Kenneth Brody wrote:

Now, this particular platform used the "normal" stack method of
passing parameters. However, I have seen platforms that pass the
first few parameters in registers (though there is only one set of
registers on those platforms), so it's certainly possible that there
is a platform which has more than one set of registers, and that
uses the registers to pass parameters, which would use different
registers depending on whether the parameter is a pointer or not.

Even for platforms that do this, it seems unlikely they'd do it for
variadic functions. There's a reason they need a prototype in scope.

True.

Yet another "real world" example of how calling a varadic function
without a prototype in scope is UB. (In this case, the compiler will
generate code to put the first several [or maybe even all] of the
parameters into registers, but the function itself assumes that all
of the parameters are on the stack.)

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer .h|
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:Th***** ********@gmail. com>