pointer to string and then back to pointer on a 64 bit machine.

[let_the_best_man_win]

How do I print a pointer address into a string buffer and then read it
back on a 64 bit machine ?
Compulsion is to use string (char * buffer) only.

printing with %d does not capture the full 64-bits of the pointer.
does %l exist in both printf and scanf for this purpose ?

 

[let_the_best_man_win]

atol does not work !
It does not bring back the correct value from the string buffer.
sscanf with %lu does it very well.


#include <stdio.h>

int main () {
char *p = (char *)182947876880;
char *p2;
char buf[100];

printf ("\n\n");
printf ("lu = %lu\n", p);

sprintf (buf, "%lu", p);
printf ("buf = %s\n", buf);

p2 = (char *)atol (buf); // THIS LINE DOES NOT WORK
sscanf (buf, "%lu", &p2); // sscanf DOES THE EXPECTED JOB
printf ("lu = %lu\n", p2);

if (p==p2) {
printf ("equal\n");
} else {
printf ("NOT equal\n");
}

printf ("\n\n");
}

 

[Ian Collins]

How do I print a pointer address into a string buffer and then read it
back on a 64 bit machine ?
Compulsion is to use string (char * buffer) only.

printing with %d does not capture the full 64-bits of the pointer.
does %l exist in both printf and scanf for this purpose ?

That's because %d isn't for pointers, %p is.

 

[let_the_best_man_win]

Is there a corresponding %p in sscanf ?

 

[let_the_best_man_win]

yes there is...
I replaced %lu with %p in the above program and it worked !

thanks for the help !

 

[Ian Collins]

Is there a corresponding %p in sscanf ?

Corresponding to what? Please provide enough context for your message
to make sense on its own.

What does you book/documentation tell you about %p in sscanf?

 

[Martin Ambuhl]

How do I print a pointer address into a string buffer and then read it
back on a 64 bit machine ?
Compulsion is to use string (char * buffer) only.

printing with %d does not capture the full 64-bits of the pointer.
does %l exist in both printf and scanf for this purpose ?

Your references to a "64 bit machine" suggest that you don't really
understand pointers. They are to an address space for which the values
may not correspond to any physical address on your machine.

And "%d" is a specifier for signed ints, not for pointers. Check the
code below for hints about how to do what you _may_ (or may not) be
meaning to do. Your question is underspecified, as I'm sure you will
realize on reflection.

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *buffer;
size_t n;

/* find out what the length of the string needs to be */
n = snprintf(0, 0, "%p", (void *) &buffer);

/* allocate the space */
if (!(buffer = malloc(n + 1))) {
fprintf(stderr, "could not allocate space for buffer.\n"
"giving up ...\n");
exit(EXIT_FAILURE);
}

/* put the address of buffer into buffer and show it */
sprintf(buffer, "%p", (void *) buffer);
printf("The buffer is at %p, and contains the string \"%s\"\n",
(void *) buffer, buffer);

free(buffer);
return 0;
}

The buffer is at 20d98, and contains the string "20d98"

 

[Richard]

Your references to a "64 bit machine" suggest that you don't really
understand pointers. They are to an address space for which the

How do you figure that out? He might have got the wrong specifier for a
pointer but that was about it. A 64 bit machine running a program
compiled for 64 bit will almost certainly have 64 bit pointers. Or?

 

[Martin Ambuhl]

atol does not work !
It does not bring back the correct value from the string buffer.
sscanf with %lu does it very well.

atol is to convert strings to longs, which are integers.
Pointers are not long ints, or any kind of integer.
Using "%lu" is an error as well.

#include <stdio.h>

int main () {
char *p = (char *)182947876880;
char *p2;
char buf[100];

printf ("\n\n");
printf ("lu = %lu\n", p);

sprintf (buf, "%lu", p);
printf ("buf = %s\n", buf);

p2 = (char *)atol (buf); // THIS LINE DOES NOT WORK
sscanf (buf, "%lu", &p2); // sscanf DOES THE EXPECTED JOB
printf ("lu = %lu\n", p2);

if (p==p2) {
printf ("equal\n");
} else {
printf ("NOT equal\n");
}

printf ("\n\n");
}

 

[Lew Pitcher]

How do you figure that out? He might have got the wrong specifier for a
pointer but that was about it. A 64 bit machine running a program
compiled for 64 bit will almost certainly have 64 bit pointers. Or?

I suppose so, but...

1) the OP didn't make it clear that the machine from which he will
print the pointer is a 64bit machine.

2) Unless the pointer is being printed and the printed value read in
the same invocation of the same program (that is, using a printed
value as a temporary storage for a pointer), then the thing pointed to
by the pointer is probably /not/ available to the program reading the
pointer. Hopefully, the program reading the printed pointer value
doesn't want the data pointed to by the pointer.

 

[Martien verbruggen]

[snip intermediate discussion]

1) the OP didn't make it clear that the machine from which he will
print the pointer is a 64bit machine.

He probably did intend it though. His original question is maybe a bit
ambiguous; 'on a 64 bit machine' can, if you want, just refer to 'read
it back', but it can also refer to the the whole previous sentence,
which, I think, is more likely.

Especially, since later in the OP we find:

which, to me at least, resolves the ambiguity. I fail to see why the
poster would say this if they were printing the pointer on a machine
with a different configuration.

Also note that the OP did not say that he wanted to print to a file,
socket, or other external medium which then could be read somewhere
else, or even by another invocation of the same program. The poster
states that they want to print to a string buffer. Generally a string
buffer on a 32 bit machine is not available to read on a, different, 64
bit machine without some intermediate representation.

Martien

 

[CBFalconer]

How do I print a pointer address into a string buffer and then
read it back on a 64 bit machine ?

Use %p. Make sure the pointer is cast to void* for printing.

 

[let_the_best_man_win]

Use %p. Make sure the pointer is cast to void* for printing.

Why this restriction of casting to a void* ?
Shouldn't the size of all pointers be same ?
(Now please do not go on to HUGE and LONG pointers, whatever they
are !)
(I just mean simple pointers)

 

[Mark Bluemel]

Why this restriction of casting to a void* ?

We've just discussed this very thoroughly in a thread entitled "The
usage of %p in C". The executive summary is this

1) Because that's what the language specifies.

2) Why not work with the language rather than against it?

Shouldn't the size of all pointers be same ?

Not necessarily. And it's not just the size that is relevant. Read the
thread cited above.

 

[CBFalconer]

Why this restriction of casting to a void* ?
Shouldn't the size of all pointers be same ?

No. All pointers can be cast to void* and back to the same type.

 

[cr88192]

Is there a corresponding %p in sscanf ?

hopefully you are not storing pointers in files...

just be aware, a pointer is (in general) only valid within a particular
instance of an app.
as a result, saving pointers into a file, or transferring them between
instances, is a bad idea (in the next run, or on the other other box, or
just in another process, the pointer can point to something completely
different).

within the same instance of the same app it is ok though, or (for most
things) between different threads in the same instance.

or such...

 

[Tor Rustad]

CBFalconer wrote:

[...]

No. All pointers can be cast to void* and back to the same type.

Nope. All pointers to objects can, but there is no such guarantee for
function pointers.

 

[CBFalconer]

CBFalconer wrote:

[...]

No. All pointers can be cast to void* and back to the same type.

Nope. All pointers to objects can, but there is no such guarantee
for function pointers.

True. I know that, but never seem to remember to mention it.

 

[Barry Schwarz]

Why this restriction of casting to a void* ?

Because the answer to the next question is no.

Shouldn't the size of all pointers be same ?

The only requirement is that void* and char* have the same size,
alignment, and representation. Other types of pointers are not
constrained this way.

(Now please do not go on to HUGE and LONG pointers, whatever they
are !)

There are no HUGE or LONG pointers in C. There are pointers to long
but C is case sensitive. And a long* need not be the same size as any
other pointer.


Remove del for email

 

[Charlie Gordon]

Your references to a "64 bit machine" suggest that you don't really
understand pointers. They are to an address space for which the values
may not correspond to any physical address on your machine.

And "%d" is a specifier for signed ints, not for pointers. Check the code
below for hints about how to do what you _may_ (or may not) be meaning to
do. Your question is underspecified, as I'm sure you will realize on
reflection.

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
char *buffer;
size_t n;

/* find out what the length of the string needs to be */
n = snprintf(0, 0, "%p", (void *) &buffer);

You compute the length of the representation of &buffer, which is the
address of the pointer, not the pointer itself.

/* allocate the space */
if (!(buffer = malloc(n + 1))) {
fprintf(stderr, "could not allocate space for buffer.\n"
"giving up ...\n");
exit(EXIT_FAILURE);
}

good, now buffer has a value, but there is no guarantee it is large enough
for the representation of its own address by %p.

/* put the address of buffer into buffer and show it */
sprintf(buffer, "%p", (void *) buffer);

bingo! potential buffer overflow

printf("The buffer is at %p, and contains the string \"%s\"\n",
(void *) buffer, buffer);

free(buffer);
return 0;
}

The buffer is at 20d98, and contains the string "20d98"

The above code is broken.