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]

Re: Memory address &quot;value&quo t;

In <1163445639.934 730.284690@h48g 2000cwc.googleg roups.com"mdh" <mdeh@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,
gordon@panix.co m I think that you could be trusted not to shaft
him." -- Robert Chang, rec.games.board

[Kenneth Brody]

Re: Memory address &quot;value&quo t;

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:ThisIsA SpamTrap@gmail. com>

[Frederick Gotham]

Re: Memory address &quot;value&quo t;

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]

Re: Memory address &quot;value&quo t;

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]

Re: Memory address &quot;value&quo t;

Kenneth Brody <kenbrody@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) kst-u@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]

Re: Memory address &quot;value&quo t;

In article <lnzmav0vu9.fsf @nuthaus.mib.or g>,
Keith Thompson <kst-u@mib.orgwrote:

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

Re: Memory address &quot;value&quo t;

Keith Thompson wrote:

>
Kenneth Brody <kenbrody@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:ThisIsA SpamTrap@gmail. com>

[Random832]

Re: Memory address &quot;value&quo t;

2006-11-15 <455B37F3.820BC F6A@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]

Re: Memory address &quot;value&quo t;

Random832 wrote:

>
2006-11-15 <455B37F3.820BC F6A@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:ThisIsA SpamTrap@gmail. com>

[Walter Roberson]

Re: Memory address &quot;value&quo t;

In article <455B37F3.820BC F6A@spamcop.net >,
Kenneth Brody <kenbrody@spamc op.netwrote:

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

The SGI "n32" and "n64" ABIs use the same registers for integers and
pointers, but different registers for float/double.

http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi/0650/bks/SGI_Developer/books/Mpro_n32_ABI/sgi_html/ch02.html

As an approximation: the Nth parameter (N from 1 to 8) is at
float register $f(11+N) if it is float or double, and at general
register $(3+N) otherwise. (So half of the registers will go unused,
but you always know the proper register by knowing the type and the
parameter number.)

In the above ABIs, varargs are always in the general registers even
if they are float/double.

In the above ABIs, floats, or structs that are one or two floats
(including Complex) are returned in floating point registers;
any other return type (including integers, pointers, small arrays,
structs and unions) that total 128 bits or smaller are returned
in general registers; any other larger return type is dealt with
by passing in a save area to receive the result with nothing returned
in registers.

This is an example of an ABI in which not having a prototype in
scope can definitely retrieve an unexpected value; it does not,
though, happen to be an ABI in which not having a prototype for
malloc() would be a problem.
--
Prototypes are supertypes of their clones. -- maplesoft