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

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

 

[Kenneth Brody]

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)==sizeof(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:[email protected]>

 

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

 

[Martin Ambuhl]

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]

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)==sizeof(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.)

 

[Walter Roberson]

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.

 

[Kenneth Brody]

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


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:[email protected]>

 

[Random832]

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]

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:[email protected]>

 

[Walter Roberson]

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