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

Author

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

let_the_best_man_win

2007-09-27, 7:57 am

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

2007-09-27, 7:57 am

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

2007-09-27, 7:57 am

let_the_best_man_win

2007-09-27, 7:57 am

Is there a corresponding %p in sscanf ?

let_the_best_man_win

2007-09-27, 7:57 am

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

thanks for the help !

Ian Collins

2007-09-27, 7:57 am

let_the_best_man_win wrote:
> 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?

--
Ian Collins.

Martin Ambuhl

2007-09-27, 7:57 am

let_the_best_man_win wrote:
> 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

2007-09-27, 7:57 am

Martin Ambuhl <mambuhl@earthlink.net> writes:

> let_the_best_man_win wrote:
>
> 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

2007-09-27, 7:57 am

let_the_best_man_win wrote:
> 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

2007-09-27, 7:57 am

On Sep 27, 7:43 am, Richard <rgr...@gmail.com> wrote:
> Martin Ambuhl <mamb...@earthlink.net> writes:
>
>
>
> 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

2007-09-27, 6:57 pm

On Thu, 27 Sep 2007 05:06:06 -0700,
Lew Pitcher <lpitcher@teksavvy.com> wrote:

[snip intermediate discussion]
[color=darkred]
> 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:
[color=darkred]

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
--
|
Martien Verbruggen | Make it idiot proof and someone will make a
| better idiot.
|

CBFalconer

2007-09-27, 6:58 pm

let_the_best_man_win wrote:
>
> 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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

let_the_best_man_win

2007-09-27, 6:58 pm

On Sep 27, 7:42 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> let_the_best_man_win wrote:
>
>
> 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

2007-09-27, 6:58 pm

let_the_best_man_win wrote:
> On Sep 27, 7:42 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
>
> 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

2007-09-27, 6:58 pm

let_the_best_man_win wrote:
>
> On Sep 27, 7:42 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
>
> 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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

cr88192

2007-09-27, 6:58 pm

"let_the_best_man_win" <sgiitnewid@gmail.com> wrote in message
news:1190886814.153072.248760@o80g2000hse.googlegroups.com...
> 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

2007-09-27, 6:58 pm

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.

--
Tor <torust [at] online [dot] no>

"Premature tuning is the root of all evil"

CBFalconer

2007-09-27, 6:58 pm

Tor Rustad wrote:
> CBFalconer wrote:
>
> [...]
>
>
> 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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

Barry Schwarz

2007-09-28, 7:57 am

On Thu, 27 Sep 2007 15:32:05 -0000, let_the_best_man_win
<sgiitnewid@gmail.com> wrote:

>On Sep 27, 7:42 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
>
>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

2007-09-29, 7:57 am

"Martin Ambuhl" <mambuhl@earthlink.net> a écrit dans le message de news:
5m1ipfFb4a26U1@mid.individual.net...
> let_the_best_man_win wrote:
>
> 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.

--
Chqrlie.

Sponsored Links