469,613 Members | 1,284 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,613 developers. It's quick & easy.

How to transfer an address value without using pointers

Hi,

I have the following program structure:

main
.....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)
.....
.....
send_data(...)
....
.....

for the function send_data, I need on its body to use the address of
A:
void send_data(...){
.....
.....
char* R=(char*) ptr;
......

but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.

At the moment I do not know how to send to the function the address
information, somebody has idea ?

Thanks in advance
Jun 27 '08 #1
69 2965
On Jun 16, 10:39 pm, Horacius ReX <horacius....@gmail.comwrote:
Hi,

I have the following program structure:

main
....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)
Don't you mean &A?
....
....
send_data(...)
send_data?
...
....

for the function send_data, I need on its body to use the address of
A:
void send_data(...){
....
....
char* R=(char*) ptr;
.....

but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.
Why?
At the moment I do not know how to send to the function the address
information, somebody has idea ?
You can define ptr to belong to the global scope.
Jun 27 '08 #2
On 16 Jun, 20:39, Horacius ReX <horacius....@gmail.comwrote:
but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.
You may well get better answers if you explain why you can't use
pointers. Is it a problem with the compiler or with your understanding
of the compiler?
Jun 27 '08 #3
Horacius ReX wrote:
Hi,

I have the following program structure:

main
....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)
No. You want:

int *ptr = &A;
....
....
send_data(...)
...
....

for the function send_data, I need on its body to use the address of
A:
void send_data(...){
....
....
char* R=(char*) ptr;
.....
This assigns to R the value derived from interpreting the contents of
ptr as a char * value.
but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.

At the moment I do not know how to send to the function the address
information, somebody has idea ?

Thanks in advance
If your system is this limited then you might try storing the address in
a appropriate integer object. If your system has them use intptr_t or
uintptr_t.

Jun 27 '08 #4
Horacius ReX wrote:
Hi,

I have the following program structure:

main
.....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)
No, ptr contains the value of A, which is 5.
To store the address of A you need
int *ptr = &A;

I suspect your subsequent problems are related to this basic error.
Jun 27 '08 #5
On Jun 16, 10:03 pm, gw7...@aol.com wrote:
On 16 Jun, 20:39, Horacius ReX <horacius....@gmail.comwrote:
but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.

You may well get better answers if you explain why you can't use
pointers. Is it a problem with the compiler or with your understanding
of the compiler?
it is a grade question, :)
Jun 27 '08 #6
On Jun 16, 9:47 pm, vipps...@gmail.com wrote:
On Jun 16, 10:39 pm, Horacius ReX <horacius....@gmail.comwrote:
Hi,
I have the following program structure:
main
....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)
Don't you mean &A?
....
....
send_data(...)
send_data?
...
....
for the function send_data, I need on its body to use the address of
A:
void send_data(...){
....
....
char* R=(char*) ptr;
.....
but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.
Why?
At the moment I do not know how to send to the function the address
information, somebody has idea ?

You can define ptr to belong to the global scope.
unfortunately cant use global scope
Jun 27 '08 #7
On Jun 16, 10:16 pm, santosh <santosh....@gmail.comwrote:
Horacius ReX wrote:
Hi,
I have the following program structure:
main
....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)

No. You want:

int *ptr = &A;
right!
>
....
....
send_data(...)
...
....
for the function send_data, I need on its body to use the address of
A:
void send_data(...){
....
....
char* R=(char*) ptr;
.....

This assigns to R the value derived from interpreting the contents of
ptr as a char * value.
but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.
At the moment I do not know how to send to the function the address
information, somebody has idea ?
Thanks in advance

If your system is this limited then you might try storing the address in
a appropriate integer object. If your system has them use intptr_t or
uintptr_t.
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address

what do you mean with intptr_t and uintptr_t ?
Jun 27 '08 #8
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?

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

void send(int ptr){
*(int*)ptr = 1201;
}

int main(void) {
int A=0;

send((int)&A);

printf("A=%d\n",A);
}
what do you mean with intptr_t and uintptr_t ?
Special int types guaranteed to be the right size for your pointers.
If you need your code to run on every computer ever made, past,
present and future, then you need to worry about stuff like this.

-- Bartc
Jun 27 '08 #9
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address

Something like this?

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

void send(int ptr){
*(int*)ptr = 1201;

}

int main(void) {
int A=0;

send((int)&A);

printf("A=%d\n",A);

}

thanks! this is really what was looking for !
Jun 27 '08 #10
Martin Ambuhl <ma*****@earthlink.netwrites:
Horacius ReX wrote:
>Hi,
I have the following program structure:
main
.....
int A=5;
int* ptr= A; (so at this point ptr stores address of A)

No, ptr contains the value of A, which is 5.
No, the declaration violates a constraint, so ptr could contain
anything at all assuming the translation unit isn't rejected.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 27 '08 #11
Horacius ReX <ho**********@gmail.comwrites:
On Jun 16, 10:03 pm, gw7...@aol.com wrote:
>On 16 Jun, 20:39, Horacius ReX <horacius....@gmail.comwrote:
but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.

You may well get better answers if you explain why you can't use
pointers. Is it a problem with the compiler or with your understanding
of the compiler?

it is a grade question, :)
Do you mean that this is a homework question?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jun 27 '08 #12
On Jun 16, 11:15*pm, Bart <b...@freeuk.comwrote:
Something like this?

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

void send(int ptr){
* *(int*)ptr = 1201;

}
If you compile this for MacOS X 64 bit (and probably some other
operating systems), this is not just likely to crash, it is one
hundred percent guaranteed to crash.
Jun 27 '08 #13
Keith Thompson wrote:
Horacius ReX <ho**********@gmail.comwrites:
>On Jun 16, 10:03 pm, gw7...@aol.com wrote:
>>On 16 Jun, 20:39, Horacius ReX <horacius....@gmail.comwrote:

but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.
You may well get better answers if you explain why you can't use
pointers. Is it a problem with the compiler or with your understanding
of the compiler?
it is a grade question, :)

Do you mean that this is a homework question?
Or that it's just too steep for him? I'd be inclined
to ignore him and slope off, leaving him to make his own pitch.

--
Eric Sosman
es*****@ieee-dot-org.invalid
Jun 27 '08 #14
On 17 juin, 01:21, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
On Jun 16, 11:15 pm, Bart <b...@freeuk.comwrote:
void send(int ptr){
*(int*)ptr = 1201;
}

If you compile this for MacOS X 64 bit (and probably some other
operating systems), this is not just likely to crash, it is one
hundred percent guaranteed to crash.
I think it's just because of the 64 bit address size that can be
bigger than an int; with a size_t it should work (and it does for me
under Linux 64 bit).
Jun 27 '08 #15
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}

thanks! this is really what was looking for !
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:

#include <stdio.h>

int send(char *str);

int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
send(s);
return 0;
}

int send(char *str) {
void *p;
sscanf(str, "%p", &p);
free(p);
return 0;
}

Or you can use (u)intptr_t.

However, all these examples use pointers in a way or another, I
suspect your homework question was made up by someone who doesn't
really know C.
Jun 27 '08 #16
On Jun 17, 5:42 am, ban-ubu...@club-internet.fr wrote:
On 17 juin, 01:21, "christian.bau" <christian....@cbau.wanadoo.co.uk>
wrote:
On Jun 16, 11:15 pm, Bart <b...@freeuk.comwrote:
void send(int ptr){
*(int*)ptr = 1201;
}
If you compile this for MacOS X 64 bit (and probably some other
operating systems), this is not just likely to crash, it is one
hundred percent guaranteed to crash.

I think it's just because of the 64 bit address size that can be
bigger than an int; with a size_t it should work (and it does for me
under Linux 64 bit).
No it shouldn't. Use intptr_t or uintptr_t.
size_t could be 2^2^2^2 bits and a pointer 2^2^2^2^2^2^2 bits for all
you know.
Jun 27 '08 #17
On Jun 17, 7:57 am, vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !

that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
Its a common trick that I use many a times. Other than the int data
type being unable to contain the pointer value, I am not aware of any
other issues. If (u)intptr_t is used, it should not be causing any
troubles.Pass me the thread on which the undefined behavior for this
scenario has been discussed.
>
#include <stdio.h>

int send(char *str);

int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
sprintf(s, "%p", malloc(1024));
Jun 27 '08 #18
On Jun 17, 7:17 am, rahul <rahulsin...@gmail.comwrote:
On Jun 17, 7:57 am, vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.

Its a common trick that I use many a times. Other than the int data
type being unable to contain the pointer value, I am not aware of any
other issues. If (u)intptr_t is used, it should not be causing any
troubles.Pass me the thread on which the undefined behavior for this
scenario has been discussed.
common trick? Don't you mean, common pitfall?
There are modern architectures where pointers are 64 bits and ints 32
bits, for example.
Jun 27 '08 #19
On Jun 17, 2:46 am, Eric Sosman <esos...@ieee-dot-org.invalidwrote:
Keith Thompson wrote:
Horacius ReX <horacius....@gmail.comwrites:
On Jun 16, 10:03 pm, gw7...@aol.com wrote:
On 16 Jun, 20:39, Horacius ReX <horacius....@gmail.comwrote:
>>but due to the limitations of the compiler (please dont ask me why :))
I can not use pointers here.
You may well get better answers if you explain why you can't use
pointers. Is it a problem with the compiler or with your understanding
of the compiler?
it is a grade question, :)
Do you mean that this is a homework question?

Or that it's just too steep for him? I'd be inclined
to ignore him and slope off, leaving him to make his own pitch.

--
Eric Sosman
esos...@ieee-dot-org.invalid
sorry, i was joking about the grade,

just mean that this is very difficult for me to handle

Jun 27 '08 #20
On Jun 17, 4:57 am, vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !

that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:

#include <stdio.h>

int send(char *str);

int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
send(s);
return 0;

}

int send(char *str) {
void *p;
sscanf(str, "%p", &p);
free(p);
return 0;

}

Or you can use (u)intptr_t.

However, all these examples use pointers in a way or another, I
suspect your homework question was made up by someone who doesn't
really know C.
in the question, pointers can be used wherever BUT in the arguments of
the function

Jun 27 '08 #21
On Jun 17, 3:57*am, vipps...@gmail.com wrote:
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
I did mention this in my reply:

H:>what do you mean with intptr_t and uintptr_t ?

B:Special int types guaranteed to be the right size for your
pointers.

I think intptr_t etc are optional in an implementation. So it is
necessary to know the right int size (long, long long etc) to use. But
this is implicit whenever int <-pointer conversion is involved.

For typical desktop machines, I don't know how common the I32 P64
model is. If the wrong int size is used, I suspect either it will work
(because the top 32 pointer bits are zero anyway), or it will soon be
found to not work! This is a job for the compiler to warn about.

I'm guessing that in this assignment it doesn't matter.
int send(char *str);
You're passing a pointer which the assignment prohibits.

--
Bartc
Jun 27 '08 #22
On Jun 17, 9:31 am, vipps...@gmail.com wrote:
On Jun 17, 7:17 am, rahul <rahulsin...@gmail.comwrote:
On Jun 17, 7:57 am, vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
Its a common trick that I use many a times. Other than the int data
type being unable to contain the pointer value, I am not aware of any
other issues. If (u)intptr_t is used, it should not be causing any
troubles.Pass me the thread on which the undefined behavior for this
scenario has been discussed.

common trick? Don't you mean, common pitfall?
There are modern architectures where pointers are 64 bits and ints 32
bits, for example.
I have not come across any such machines(not to say they don't exist).
But what I asked was apart from the overflow issue, are there any
other issues? The overflow issue is solved by using (u)intptr_t
( provided the implementation provides it).
Jun 27 '08 #23
On Jun 17, 11:13 am, Bart <b...@freeuk.comwrote:
On Jun 17, 3:57 am, vipps...@gmail.com wrote:
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.

I did mention this in my reply:

H:>what do you mean with intptr_t and uintptr_t ?

B:Special int types guaranteed to be the right size for your
pointers.
Only for valid pointers to void.
>
I think intptr_t etc are optional in an implementation. So it is
necessary to know the right int size (long, long long etc) to use. But
indeed, they are optional. It is impossible to know the 'right' size.
Regardless, it is not only about bit width.
this is implicit whenever int <-pointer conversion is involved.
I don't understand what is implicit. There is no implicit int to/from
pointer conversion, except for initializations to constant expressions
with value 0.
For typical desktop machines, I don't know how common the I32 P64
Who cares about typical desktop machines? The standard certainly
doesn't mention or care about them in the way you describe.
model is. If the wrong int size is used, I suspect either it will work
(because the top 32 pointer bits are zero anyway), or it will soon be
found to not work! This is a job for the compiler to warn about.
Yes it will or will not work, in other words, undefined behavior.
And no, the compiler doesn't have to warn. Warning are optional and
not required by the standard, and it's not a constraint violation to
cast a pointer to (int).
>
I'm guessing that in this assignment it doesn't matter.
It does.
>
int send(char *str);

You're passing a pointer which the assignment prohibits.
Indeed, in the part of my post that you snipped I say:

vippHowever, all these examples use pointers in a way or another, I
vippsuspect your homework question was made up by someone who
doesn't
vippreally know C.

Jun 27 '08 #24
On Jun 17, 11:24 am, rahul <rahulsin...@gmail.comwrote:
On Jun 17, 9:31 am, vipps...@gmail.com wrote:
On Jun 17, 7:17 am, rahul <rahulsin...@gmail.comwrote:
Its a common trick that I use many a times. Other than the int data
type being unable to contain the pointer value, I am not aware of any
other issues. If (u)intptr_t is used, it should not be causing any
troubles.Pass me the thread on which the undefined behavior for this
scenario has been discussed.
common trick? Don't you mean, common pitfall?
There are modern architectures where pointers are 64 bits and ints 32
bits, for example.

I have not come across any such machines(not to say they don't exist).
They do
But what I asked was apart from the overflow issue, are there any
other issues? The overflow issue is solved by using (u)intptr_t
( provided the implementation provides it).
The standard doesn't mention any; in fact the standard doesn't even
mention the "oveflow issue" in that case. Just let your imagination go
wild and think of some reasons.
For example, the standard also doesn't define why fseek() could fail.
In real-world applications it could fail for pipes, sockets, etc,
which are beyond the scope of the standard; the reason the
possibilities of failure of an explicit conversion from pointer to int
is not documented is so that the standard will not restrict the
language in some way.
Jun 27 '08 #25
On Jun 17, 9:29*am, vipps...@gmail.com wrote:
On Jun 17, 11:13 am, Bart <b...@freeuk.comwrote:On Jun 17, 3:57 am, vipps...@gmail.com wrote:
H:>what do you mean with intptr_t and uintptr_t ?
B:Special int types guaranteed to be the right size for your
pointers.

Only for valid pointers to void.
In that case intptr_t won't help, since we're using pointers to non-
void types.
I think intptr_t etc are optional in an implementation. So it is
necessary to know the right int size (long, long long etc) to use. But

indeed, they are optional. It is impossible to know the 'right' size.
Regardless, it is not only about bit width.
this is implicit whenever int <-pointer conversion is involved.
I don't understand what is implicit.
I meant in people's minds when they are reading example code with int/
pointer conversions. If you had to put everything necessary, a lot of
code would become obfuscated.
Who cares about typical desktop machines? The standard certainly
doesn't mention or care about them in the way you describe.
Sometimes you have to read between the lines in the standard. I would
also have had to write UB when deciding what should happen when a
pointer value is truncated. 99.9% of the time you just get those lower
bits, but some machine from 1957 did it another way so...
And no, the compiler doesn't have to warn.
If it's that big a deal, then maybe it should, and at standard warning
levels.

int send(char *str);
You're passing a pointer which the assignment prohibits.

Indeed, in the part of my post that you snipped I say:

However, all these examples use pointers in a way or another
OK.
I suspect your homework question was made up by someone who
doesn't really know C.
Maybe the question was /about/ pointer and integer conversions.

--
Bartc
Jun 27 '08 #26
On Tue, 17 Jun 2008 01:24:57 -0700, rahul wrote:
On Jun 17, 9:31 am, vipps...@gmail.com wrote:
>common trick? Don't you mean, common pitfall? There are modern
architectures where pointers are 64 bits and ints 32 bits, for example.
I have not come across any such machines(not to say they don't exist).
Almost all new desktop computers fall into this category under some of
the most common Linux distributions. I have:

tcv@rose:~ $ csizeof int
4
tcv@rose:~ $ csizeof void*
8
tcv@rose:~ $ uname -a
Linux rose 2.6.24-1-amd64 #1 SMP Sat May 10 09:28:10 UTC 2008 x86_64
GNU/Linux
My handy csizeof bash script is:
(replies on this to some other group if you please)

#! /bin/bash
# by to******@gmail.com PUBLIC DOMAIN 2007
# usage eg:
# csizeof "struct stat" sys/types.h sys/stat.h unistd.h

cname=$(tempfile --suffix=.c)
ename=$(tempfile --suffix=.exe)

cat >"$cname" <<EOF
#include <stdio.h>
#include <stdlib.h>
EOF

for (( i= 2; i <= $#; ++i ))
do
echo "#include <${!i}>" >>"$cname"
done

cat >>"$cname" <<EOF
int main(void){
fprintf( stdout, "%zu\n", sizeof($1) );
exit( EXIT_SUCCESS );
}
EOF

gcc -o "$ename" "$cname" && chmod 700 "$ename" && "$ename"
rm -f "$cname" "$ename"
Jun 27 '08 #27
On Jun 17, 12:00 pm, Bart <b...@freeuk.comwrote:
On Jun 17, 9:29 am, vipps...@gmail.com wrote:
On Jun 17, 11:13 am, Bart <b...@freeuk.comwrote:On Jun 17, 3:57 am, vipps...@gmail.com wrote:
H:>what do you mean with intptr_t and uintptr_t ?
B:Special int types guaranteed to be the right size for your
pointers.
Only for valid pointers to void.

In that case intptr_t won't help, since we're using pointers to non-
void types.
No, it's still possible to use it:
intptr_t = (intptr_t)(void *)any_ptr_type;
any_ptr_type = (void *)intptr_t_object
I think intptr_t etc are optional in an implementation. So it is
necessary to know the right int size (long, long long etc) to use. But
indeed, they are optional. It is impossible to know the 'right' size.
Regardless, it is not only about bit width.
this is implicit whenever int <-pointer conversion is involved.
I don't understand what is implicit.

I meant in people's minds when they are reading example code with int/
pointer conversions. If you had to put everything necessary, a lot of
code would become obfuscated.
No it would not, if yo don't put everything necessary the code is
quite possibly errornous.
Who cares about typical desktop machines? The standard certainly
doesn't mention or care about them in the way you describe.

Sometimes you have to read between the lines in the standard. I would
also have had to write UB when deciding what should happen when a
pointer value is truncated. 99.9% of the time you just get those lower
bits, but some machine from 1957 did it another way so...
Wrong.
And no, the compiler doesn't have to warn.

If it's that big a deal, then maybe it should, and at standard warning
levels.
Actually it's up to the compiler whether to warn or not. It's not a
constraint violation and therefore does not require a diagnostic
message from the compiler, and I've already explained that in the part
that you snipped. Please don't snip parts of my post that are relevant
to the discussion.
Jun 27 '08 #28
Horacius ReX wrote:
On Jun 17, 4:57 am, vipps...@gmail.com wrote:
>On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but
dont know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !

that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:

#include <stdio.h>

int send(char *str);

int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
send(s);
return 0;

}

int send(char *str) {
void *p;
sscanf(str, "%p", &p);
free(p);
return 0;

}

Or you can use (u)intptr_t.

However, all these examples use pointers in a way or another, I
suspect your homework question was made up by someone who doesn't
really know C.

in the question, pointers can be used wherever BUT in the arguments of
the function
Well then, make the function receive a struct object and encapsulate
your pointer in it. Or make the pointer file scope and access it
directly within your function.

Jun 27 '08 #29
On 17 Jun, 08:28, Horacius ReX <horacius....@gmail.comwrote:

<snip>
in the question, pointers can be used wherever BUT in the arguments of
the function
so this IS homework! You lied to us.

--
nick keighley
Jun 27 '08 #30

"viza" <to******@gmil.comwrote in message
news:IX****************@newsfe21.ams2...
On Tue, 17 Jun 2008 01:24:57 -0700, rahul wrote:
>On Jun 17, 9:31 am, vipps...@gmail.com wrote:
>>common trick? Don't you mean, common pitfall? There are modern
architectures where pointers are 64 bits and ints 32 bits, for example.
>I have not come across any such machines(not to say they don't exist).

Almost all new desktop computers fall into this category under some of
the most common Linux distributions. I have:

tcv@rose:~ $ csizeof int
4
tcv@rose:~ $ csizeof void*
8
There must be an option to select the int/pointer size surely?

Many appls would be quite happy to stay with 32-bit pointers; 64-bit ones
would just waste memory, bandwidth and performance.

For my main appl, 64-bit data (ie. 64-bit moves) would help tremendously,
but if all my data doubled in size then I'm back where I started.

--
Bartc
Jun 27 '08 #31
Bartc wrote:
"viza" <to******@gmil.comwrote in message
news:IX****************@newsfe21.ams2...
>On Tue, 17 Jun 2008 01:24:57 -0700, rahul wrote:
>>On Jun 17, 9:31 am, vipps...@gmail.com wrote:
common trick? Don't you mean, common pitfall? There are modern
architectures where pointers are 64 bits and ints 32 bits, for example.
I have not come across any such machines(not to say they don't exist).
Almost all new desktop computers fall into this category under some of
the most common Linux distributions. I have:

tcv@rose:~ $ csizeof int
4
tcv@rose:~ $ csizeof void*
8
All popular desktop OSs (even 64 bit windows) use this model.
>
There must be an option to select the int/pointer size surely?
All decent compiler systems on 64 bit systems can build 64 or 32 bit
applications.

--
Ian Collins.
Jun 27 '08 #32
On Tue, 17 Jun 2008 15:33:39 +0000, Bartc wrote:
"viza" <to******@gmil.comwrote in message
>I have:

$ csizeof int
4
$ csizeof void*
8

There must be an option to select the int/pointer size surely?
Use appropriate types. Try long, and maybe long long.
Many appls would be quite happy to stay with 32-bit pointers; 64-bit
ones would just waste memory, bandwidth and performance.
If the registers are that big, then you waste more time converting up and
back. Also, when you run 32 but apps on amd64 (IA64T or AMD64) it is
also slowed by not using the new registers, and the less efficient
calling convention. If you want to design a system that uses the new
features but saves a bit of space by using smaller pointers you will
probably have to write your own compiler.
For my main appl, 64-bit data (ie. 64-bit moves) would help
tremendously, but if all my data doubled in size then I'm back where I
started.
memcpy() etc. should already be optimised to use the biggest size it can.

Jun 27 '08 #33
viza wrote:
On Tue, 17 Jun 2008 15:33:39 +0000, Bartc wrote:
<snip>
>Many appls would be quite happy to stay with 32-bit pointers; 64-bit
ones would just waste memory, bandwidth and performance.

If the registers are that big, then you waste more time converting up
and back. Also, when you run 32 but apps on amd64 (IA64T or AMD64) it
is also slowed by not using the new registers, and the less efficient
calling convention. If you want to design a system that uses the new
features but saves a bit of space by using smaller pointers you will
probably have to write your own compiler.
Also, in a typical program the number of pointer objects is much less
than the number of data objects. So any space saved by retaining 32 bit
pointers is not likely to make a significant difference.

<snip>

Jun 27 '08 #34

"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.org...
viza wrote:
>On Tue, 17 Jun 2008 15:33:39 +0000, Bartc wrote:

<snip>
>>Many appls would be quite happy to stay with 32-bit pointers; 64-bit
ones would just waste memory, bandwidth and performance.

If the registers are that big, then you waste more time converting up
and back. Also, when you run 32 but apps on amd64 (IA64T or AMD64) it
is also slowed by not using the new registers, and the less efficient
calling convention. If you want to design a system that uses the new
features but saves a bit of space by using smaller pointers you will
probably have to write your own compiler.

Also, in a typical program the number of pointer objects is much less
than the number of data objects. So any space saved by retaining 32 bit
pointers is not likely to make a significant difference.
One of my structs would increase from 16-bytes to at least 24-bytes; that's
one pointer and one length needing to be doubled. Because 24 is 'odd' it
would probably be extended to 32-bytes. Arrays of this struct would be
double the size for no good reason if the total of all data is below 2GB.

I would imagine that for many programs in 64-bits, the machine would spend
much of it's time pushing around pointers where the top half is zero. Or,
where it would previously push 2 32-bit params for a function, it would now
have to push 2 64-bit params to satisfy the stack width. Again lots of zeros
being moved about. It could have pushed those 2 32-bit values, if
consecutive, in one instruction.

--
Bartc
Jun 27 '08 #35
On Mon, 16 Jun 2008 19:57:16 -0700 (PDT), vi******@gmail.com wrote:
>On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
>On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}

thanks! this is really what was looking for !

that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:

#include <stdio.h>

int send(char *str);

int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
Did you mean %p?
send(s);
return 0;
}

int send(char *str) {
void *p;
sscanf(str, "%p", &p);
free(p);
return 0;
}

Or you can use (u)intptr_t.

However, all these examples use pointers in a way or another, I
suspect your homework question was made up by someone who doesn't
really know C.

Remove del for email
Jun 27 '08 #36
On Jun 17, 7:57*am, vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:


On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
* *(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what *was looking for !

that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:

#include <stdio.h>

int send(char *str);

int main(void) {
* char s[512];
* sprintf(s, "p", malloc(1024));
* send(s);
* return 0;

}

int send(char *str) {
* void *p;
* sscanf(str, "%p", &p);
* free(p);

I think this free(p) will show undefined behavior. According to my
understanding we should not try to free any memory using function
free() if the memory is not obtained through malloc or realloc .
In the above code pointer p (void *p) is not obtained using malloc
or realloc . So would it not cause undefined behavior ?

* return 0;

}

Or you can use (u)intptr_t.

However, all these examples use pointers in a way or another, I
suspect your homework question was made up by someone who doesn't
really know C.- Hide quoted text -

Jun 27 '08 #37
On Jun 18, 8:30 am, somenath <somenath...@gmail.comwrote:
On Jun 17, 7:57 am, vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:
#include <stdio.h>
int send(char *str);
int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
send(s);
return 0;
}
int send(char *str) {
void *p;
sscanf(str, "%p", &p);
free(p);

I think this free(p) will show undefined behavior. According to my
understanding we should not try to free any memory using function
free() if the memory is not obtained through malloc or realloc .
In the above code pointer p (void *p) is not obtained using malloc
or realloc . So would it not cause undefined behavior ?
return 0;
}
sscanf() will presumably fail the conversion and an uninitialized
pointer will be freed. Not (void *)"p" or anything like that.
It was my mistake. I thought it would work, but apparently it doesn't.
I have a poor understanding of C.
Jun 27 '08 #38
On Jun 18, 8:03 am, Barry Schwarz <schwa...@dqel.comwrote:
On Mon, 16 Jun 2008 19:57:16 -0700 (PDT), vipps...@gmail.com wrote:
On Jun 17, 1:58 am, Horacius ReX <horacius....@gmail.comwrote:
On Jun 17, 12:15 am, Bart <b...@freeuk.comwrote:
yes, i tried tranferring an int with the address "coded", but dont
know how to use later in the function this address
Something like this?
#include <stdio.h>
#include <stdlib.h>
void send(int ptr){
*(int*)ptr = 1201;
}
int main(void) {
int A=0;
send((int)&A);
printf("A=%d\n",A);
}
thanks! this is really what was looking for !
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:
#include <stdio.h>
int send(char *str);
int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));

Did you mean %p?
No, I did not mean %p. Apparently, p does not do what I thought it
does.
Jun 27 '08 #39
Bartc wrote:
>
I would imagine that for many programs in 64-bits, the machine would spend
much of it's time pushing around pointers where the top half is zero. Or,
where it would previously push 2 32-bit params for a function, it would now
have to push 2 64-bit params to satisfy the stack width. Again lots of zeros
being moved about. It could have pushed those 2 32-bit values, if
consecutive, in one instruction.
Which is why applications on 64 bit systems tend to be built as 32 bit
unless they require the extra address range.

--
Ian Collins.
Jun 27 '08 #40
vi******@gmail.com writes:
On Jun 18, 8:30 am, somenath <somenath...@gmail.comwrote:
>On Jun 17, 7:57 am, vipps...@gmail.com wrote:
<snip>
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:
#include <stdio.h>
int send(char *str);
int main(void) {
char s[512];
sprintf(s, "p", malloc(1024));
send(s);
return 0;
}
int send(char *str) {
void *p;
sscanf(str, "%p", &p);
free(p);

I think this free(p) will show undefined behavior. According to my
understanding we should not try to free any memory using function
“free()” if the memory is not obtained through malloc or realloc .
In the above code pointer “p” (void *p) is not obtained using malloc
or realloc . So would it not cause undefined behavior ?
return 0;
}
sscanf() will presumably fail the conversion and an uninitialized
pointer will be freed. Not (void *)"p" or anything like that.
It was my mistake. I thought it would work, but apparently it doesn't.
I have a poor understanding of C.
You are too hard on yourself. You rejected and earlier correction of
the sprintf format to "%p" saying that was not what you meant, but I
can't see what else you could mean. For the record, unless I have got
it all wrong, this is perfectly well defined:

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

void send(char *str);

int main(void)
{
char s[512];
sprintf(s, "%p", malloc(1024));
send(s);
return 0;
}

void send(char *str)
{
void *p;
sscanf(str, "%p", &p);
free(p);
}

and does not have any memory leaks. If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. All %p does is represent the pointer as text in a
reversible way.

--
Ben.
Jun 27 '08 #41
On Jun 18, 4:54*pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
vipps...@gmail.com writes:
On Jun 18, 8:30 am, somenath <somenath...@gmail.comwrote:
On Jun 17, 7:57 am, vipps...@gmail.com wrote:
<snip>
that code invokes undefined behavior. I've already explained to Bart
why, but he doesn't seem to appreciate my advice.
You can do this:
#include <stdio.h>
int send(char *str);
int main(void) {
* char s[512];
* sprintf(s, "p", malloc(1024));
* send(s);
* return 0;
}
int send(char *str) {
* void *p;
* sscanf(str, "%p", &p);
* free(p);
I think this free(p) will show undefined behavior. According to my
understanding we should not try to free any memory using function
free() if the memory is not obtained through malloc or realloc .
In the above code *pointer *p (void *p) is not obtained using malloc
or realloc . So would it not cause undefined behavior ?
* return 0;
}
sscanf() will presumably fail the conversion and an uninitialized
pointer will be freed. Not (void *)"p" or anything like that.
It was my mistake. I thought it would work, but apparently it doesn't.
I have a poor understanding of C.

You are too hard on yourself. *You rejected and earlier correction of
the sprintf format to "%p" saying that was not what you meant, but I
can't see what else you could mean. *For the record, unless I have got
it all wrong, this is perfectly well defined:

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

void send(char *str);

int main(void)
{
* * *char s[512];
* * *sprintf(s, "%p", malloc(1024));
* * *send(s);
* * *return 0;

}

void send(char *str)
{
* * *void *p;
* * *sscanf(str, "%p", &p);
* * *free(p);

}

and does not have any memory leaks. *If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. *All %p does is represent the pointer as text in a
reversible way.
Could you please explain why it wont show undefined behavior?
When I ran this code I get
Segmentation fault (core dumped).

I think it would be free(str) instead of free(p).
Please correct me if my understanding is wrong.
Jun 27 '08 #42
somenath <so*********@gmail.comwrites:
On Jun 18, 4:54*pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
<snip>
>#include <stdio.h>
#include <stdlib.h>

void send(char *str);

int main(void)
{
* * *char s[512];
* * *sprintf(s, "%p", malloc(1024));
* * *send(s);
* * *return 0;

}

void send(char *str)
{
* * *void *p;
* * *sscanf(str, "%p", &p);
* * *free(p);

}
<snip>
Could you please explain why it won’t show undefined behavior?
When I ran this code I get
Segmentation fault (core dumped).
Exactly the code above gives you a segmentation fault? If so, what
compiler it it? I can only point to what the standard says about the
%p format which is that you can convert a pointer to text and back
again.
I think it would be free(str) instead of free(p).
That would be quite wrong. str is a parameter, initialised with a
pointer to an array with automatic storage duration. You can't
pass such a pointer to free.

--
Ben.
Jun 27 '08 #43
somenath wrote:
On Jun 18, 4:54*pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
[ ... ]
>*For the record, unless I have got it all wrong, this is perfectly
*well defined:

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

void send(char *str);

int main(void)
{
char s[512];
sprintf(s, "%p", malloc(1024));
send(s);
return 0;

}

void send(char *str)
{
void *p;
sscanf(str, "%p", &p);
free(p);

}

and does not have any memory leaks. *If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. *All %p does is represent the pointer as text in
a reversible way.

Could you please explain why it won?t show undefined behavior?
Where do you think it *should* invoke undefined behaviour?
When I ran this code I get
Segmentation fault (core dumped).
Strange. I get no such errors. Are you sure you compiled exactly the
code above?
I think it would be free(str) instead of free(p).
No. In main sprintf is used to convert the pointer value returned by
malloc (which could be NULL) to an implementation defined text format
and store it in the array 's.' This is then supplied as the argument to
the send function which accesses 's' as the local 'str'. Now sscanf is
used to convert the implementation defined text format of the pointer
value in 's' back to a void * value which is then assigned to
local 'p', which in turn is supplied to free.

As far as I can see, everthing is well defined, except perhaps one ought
to use an unsigned char array instead of a plain char one for 's.'
Please correct me if my understanding is wrong.
Jun 27 '08 #44
santosh <sa*********@gmail.comwrites:
somenath wrote:
>On Jun 18, 4:54*pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
<in essence:>
>>char s[512];
sprintf(s, "%p", malloc(1024));
....
>>void *p;
sscanf(str, "%p", &p);
free(p);
<snip>
As far as I can see, everthing is well defined, except perhaps one ought
to use an unsigned char array instead of a plain char one for 's.'
Why do you suggest that? I note the "perhaps", but I can' see *any*
advantage at all in this particular case.

--
Ben.
Jun 27 '08 #45
Ben Bacarisse wrote:
santosh <sa*********@gmail.comwrites:
>somenath wrote:
>>On Jun 18, 4:54*pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
<in essence:>
>>>char s[512];
sprintf(s, "%p", malloc(1024));
...
>>>void *p;
sscanf(str, "%p", &p);
free(p);
<snip>
>As far as I can see, everthing is well defined, except perhaps one
ought to use an unsigned char array instead of a plain char one for
's.'

Why do you suggest that? I note the "perhaps", but I can' see *any*
advantage at all in this particular case.
I'm sorry, you're right. There is no difference in either case. I was
confused by a post in a different thread.

Jun 27 '08 #46
On Jun 18, 2:54 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
For the record, unless I have got
it all wrong, this is perfectly well defined:

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

void send(char *str);

int main(void)
{
char s[512];
sprintf(s, "%p", malloc(1024));
send(s);
return 0;

}

void send(char *str)
{
void *p;
sscanf(str, "%p", &p);
free(p);

}

and does not have any memory leaks. If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. All %p does is represent the pointer as text in a
reversible way.
There's just one thing about this code that can fail: the sprintf()
line, *if* the text representation of a pointer is more than 510 bytes
long.
Unfortunately, the only way this seems solvable in C89 is:

/* ... */
FILE *fp = tempfile;
int rc = fprintf(tempfile, "%p", (void *)ptr);
/* check rc */
/* if all okay, */
char *s = malloc(rc + 1);
if(ptr) {
sprintf(s, "%p", (void *)ptr);
/* ... */

In C99, it's possible to use snprintf() in various ways, such as with
a fixed size array:

int rc;
char s[512];
rc = snprintf(s, sizeof s, "%p", (void *)s);

Or,

char *ptr = malloc(snprintf(NULL, 0, "%p", (void *)valid_ptr));
if(ptr)
sprintf(ptr, "%p", (void *)valid_ptr);
free(ptr);

But I don't think there's a chance in the *near* future that the
representation of a pointer in text shall require 512 bytes.
Jun 27 '08 #47
vi******@gmail.com wrote:
On Jun 18, 2:54 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>For the record, unless I have got
it all wrong, this is perfectly well defined:

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

void send(char *str);

int main(void)
{
char s[512];
sprintf(s, "%p", malloc(1024));
send(s);
return 0;

}

void send(char *str)
{
void *p;
sscanf(str, "%p", &p);
free(p);

}

and does not have any memory leaks. If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. All %p does is represent the pointer as text in
a reversible way.
There's just one thing about this code that can fail: the sprintf()
line, *if* the text representation of a pointer is more than 510 bytes
long.
Unfortunately, the only way this seems solvable in C89 is:

/* ... */
FILE *fp = tempfile;
A typo. I'm sure you meant:

FILE *fp = tmpfile();

Also the call could fail.
int rc = fprintf(tempfile, "%p", (void *)ptr);
/* check rc */
/* if all okay, */
char *s = malloc(rc + 1);
if(ptr) {
Do you mean if(s) here?
sprintf(s, "%p", (void *)ptr);
/* ... */

In C99, it's possible to use snprintf() in various ways, such as with
a fixed size array:

int rc;
char s[512];
rc = snprintf(s, sizeof s, "%p", (void *)s);
Or with a VLA:

char ptr[snprintf(NULL, 0, "%p", (void *)valid_ptr)+1];
Or,

char *ptr = malloc(snprintf(NULL, 0, "%p", (void *)valid_ptr));
if(ptr)
sprintf(ptr, "%p", (void *)valid_ptr);
free(ptr);

But I don't think there's a chance in the *near* future that the
representation of a pointer in text shall require 512 bytes.
Yes.

Jun 27 '08 #48
On Jun 18, 5:01 pm, santosh <santosh....@gmail.comwrote:
vipps...@gmail.com wrote:
On Jun 18, 2:54 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
For the record, unless I have got
it all wrong, this is perfectly well defined:
#include <stdio.h>
#include <stdlib.h>
void send(char *str);
int main(void)
{
char s[512];
sprintf(s, "%p", malloc(1024));
send(s);
return 0;
}
void send(char *str)
{
void *p;
sscanf(str, "%p", &p);
free(p);
}
and does not have any memory leaks. If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. All %p does is represent the pointer as text in
a reversible way.
There's just one thing about this code that can fail: the sprintf()
line, *if* the text representation of a pointer is more than 510 bytes
long.
Unfortunately, the only way this seems solvable in C89 is:
/* ... */
FILE *fp = tempfile;

A typo. I'm sure you meant:

FILE *fp = tmpfile();

Also the call could fail.
I'm on fire today, three errors in 2 posts!
int rc = fprintf(tempfile, "%p", (void *)ptr);
/* check rc */
/* if all okay, */
char *s = malloc(rc + 1);
if(ptr) {

Do you mean if(s) here?
Yep
>
sprintf(s, "%p", (void *)ptr);
/* ... */
In C99, it's possible to use snprintf() in various ways, such as with
a fixed size array:
int rc;
char s[512];
rc = snprintf(s, sizeof s, "%p", (void *)s);

Or with a VLA:

char ptr[snprintf(NULL, 0, "%p", (void *)valid_ptr)+1];
No, it is not guaranteed that the text representation of a pointer is
less than 65534 bytes.
(ISO C99 TC3, 5.2.4.1 - Environmental limits)
Or,
char *ptr = malloc(snprintf(NULL, 0, "%p", (void *)valid_ptr));
if(ptr)
sprintf(ptr, "%p", (void *)valid_ptr);
free(ptr);
But I don't think there's a chance in the *near* future that the
representation of a pointer in text shall require 512 bytes.

Yes.
Well, what about my 'nitpicki-er' 65535 bytes? :-)
Jun 27 '08 #49
vi******@gmail.com writes:
On Jun 18, 2:54 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
>For the record, unless I have got
it all wrong, this is perfectly well defined:

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

void send(char *str);

int main(void)
{
char s[512];
sprintf(s, "%p", malloc(1024));
send(s);
return 0;

}

void send(char *str)
{
void *p;
sscanf(str, "%p", &p);
free(p);

}

and does not have any memory leaks. If you mean that what you were
proposing would not work when the part doing the sprintf and the part
doing the sscanf have separate address spaces, then yes you are right
that it won't work. All %p does is represent the pointer as text in a
reversible way.
There's just one thing about this code that can fail: the sprintf()
line, *if* the text representation of a pointer is more than 510 bytes
long.
Good point. That really just means it is not portable. The %p format
is implementation defined, so one can be sure it will not fail if your
library documents the maximum length.

--
Ben.
Jun 27 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.