Problem with a Pointer

[ghyott]

hello,
Can somebody please tell me that why the the value of "ret" is not
changing even by the statement (*ret)+=26; . The printf statement
prints the same value of ret both the times.
Also when I ran this program on gcc it executed normally but the same
program crashed on MS visual studio .Net.

#include <stdio.h>

void funct(int a ,int b,int c)
{
char buf[5];
char buf1[10];
int *ret;
ret=buf+12;
printf("ret is %x\n",ret);
(*ret)+=26;
printf("ret is %x\n",ret);

return ;
}

int main(void)
{
int i;
i=0;
funct(1,2,3);
i=34;
printf("%d\n",i);
return 0;
}

[pete]

gh****@yahoo.com wrote:

hello,
Can somebody please tell me that why the the value of "ret" is not
changing even by the statement (*ret)+=26; .
Because (ret) and (*ret) are two different objects.
ret=buf+12;
printf("ret is %x\n",ret);
(*ret)+=26;
printf("ret is %x\n",ret);

--
pete

[Christian Kandeler]

gh****@yahoo.com wrote:

#include <stdio.h>

void funct(int a ,int b,int c)
{
char buf[5];
char buf1[10];
int *ret;
ret=buf+12;
printf("ret is %x\n",ret);
(*ret)+=26;
Undefined behavior for at least two reasons: First, buf is a char array and
may therefore not be suitably aligned for an access to an int. Second, even
if alignment happens to be okay, buf + 12 is not part of the array, which
has only five members, and you don't know if the memory belongs to you.
printf("ret is %x\n",ret);
Additionally, even if you didn't make the mistakes mentioned, ret would
still be the same here, because you have not changed its value, but the
value of the int it (potentially) points to.

return ;
}

You have not used any of the function's arguments.
Christian

[bjrnove]

Hi.

One problem here is that ret points to a position that's not inside the
memory for buf.

char buf[5];
char buf1[10];
int *ret;
ret=buf+12;

The assignment of buf to ret should cause your compiler to give you a
warning. Remember to cast.

ret = (int*)(buf + 12);

Another thing is that buf has the size of 5 bytes. You set the pointer
to the start of buf + 12, or in other words buf[12] witch doesn't
exist. This wil cause undefined bevaior acording to the standard.

--
bjrnove

[Eric Sosman]

bjrnove wrote:

[...]
char buf[5];
char buf1[10];
int *ret;
ret=buf+12;

The assignment of buf to ret should cause your compiler to give you a
warning. Remember to cast.

ret = (int*)(buf + 12);

That's like taking the batteries out of the smoke alarm
because it keeps waking you up at night. The diagnostic is
drawing attention to a real, actual error: If you succeed in
silencing it, the error itself still remains. Sleep soundly!

--
Eric Sosman
es*****@acm-dot-org.invalid

[bjrnove]

> That's like taking the batteries out of the smoke alarm

because it keeps waking you up at night. The diagnostic is
drawing attention to a real, actual error: If you succeed in
silencing it, the error itself still remains. Sleep soundly!

I see your point, but I mention this in the text below what you quoted.
:-)

[Eric Sosman]

bjrnove wrote:

[Use a cast to hide `char*'-to-`int*' error]
[Eric Sosman wrote (attribution missing)]:

That's like taking the batteries out of the smoke alarm
because it keeps waking you up at night. The diagnostic is
drawing attention to a real, actual error: If you succeed in
silencing it, the error itself still remains. Sleep soundly!

I see your point, but I mention this in the text below what you quoted.

The additional text referred to the out-of-bounds error,
which is unrelated to the error the cast attempts to hide.
See Christian Kandeler's response for an explanation of both
errors, and of some other peculiarities of the O.P.'s code.

--
Eric Sosman
es*****@acm-dot-org.invalid

[ghyott]

First of all,I apologise for posting a moronic question.
I made a foolish mistake(taking ret in place of *ret ) while I was
trying to debug
my problem.
I have taken ret+12,because it now the ret will point to the return
address of the
funct(...).Next step i.e. (*ret)+=23; changes the return address to
another specified address,so the control will jump to some other
location instead of going to its intended location which was set when
the funct was called.
Although, it was looking easy but the things were not going as planned
and I still don't know why it is so?

[Stephen Sprunk]

<gh****@yahoo.com> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

First of all,I apologise for posting a moronic question.
I made a foolish mistake(taking ret in place of *ret ) while I was
trying to debug my problem.
I have taken ret+12,because it now the ret will point to the return
address of the funct(...).
(ret+12) points to an unspecified location. There is no guarantee that
location has _anything_ to do with the return address of the function, that
your program owns that memory, or that it's even a valid address.
Next step i.e. (*ret)+=23; changes the return address to
another specified address,
No, it changes the value of some unspecified data in an unspecified
location -- unless the pointer is invalid and the system traps it, in which
case your program terminates.
so the control will jump to some other location instead of going to its
intended location which was set when the funct was called.
No, it invokes undefined behavior. The data at (ret+12) might happen to be
your oven's temperature, and changing it could burn your dinner. Or it
might do what you think it does. You have no way of knowing.
Although, it was looking easy but the things were not going as planned
and I still don't know why it is so?

It's not going as planned because you're expecting undefined behavior to be
reliable, and it isn't. Even if it seems to work at one time, it could fail
next time you recompile due to a new version, different optimization, etc.
It's certainly unlikely to work on a different platform.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[CBFalconer]

Stephen Sprunk wrote:

<gh****@yahoo.com> wrote in message

First of all,I apologise for posting a moronic question. I made
a foolish mistake(taking ret in place of *ret ) while I was
trying to debug my problem. I have taken ret+12,because it now
the ret will point to the return address of the funct(...).

(ret+12) points to an unspecified location. There is no guarantee
that location has _anything_ to do with the return address of the
function, that your program owns that memory, or that it's even a
valid address.

The very fact that this joker mentions the return address shows
that s/he/it is attempting some form of malware.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[ghyott]

The very fact that this joker mentions the return address shows
that s/he/it is attempting some form of malware.

The very fact that you calls Trisdale "Trollsdare" and me a joker shows
that
you are a real bastard.
And for your kind information I am not attempting some form of malware.

[Martin Ambuhl]

gh****@yahoo.com wrote:

hello,
Can somebody please tell me that why the the value of "ret" is not
changing even by the statement (*ret)+=26; .
#include <stdio.h>

void funct(int a ,int b,int c)
{
char buf[5];
char buf1[10];
int *ret;
ret=buf+12;
This is insane. buf is a char[5]. The location buf+12 is outside it
and you have *no* idea where it is. This is a gross error that you
should quickly get over.
printf("ret is %x\n",ret);
(*ret)+=26;

You have no idea that ret points to anything you can use. It is insane
to dereference it.

[Stephen Sprunk]

"CBFalconer" <cb********@yahoo.com> wrote in message
news:42***************@yahoo.com...

Stephen Sprunk wrote:

<gh****@yahoo.com> wrote in message

First of all,I apologise for posting a moronic question. I made
a foolish mistake(taking ret in place of *ret ) while I was
trying to debug my problem. I have taken ret+12,because it now
the ret will point to the return address of the funct(...).

(ret+12) points to an unspecified location. There is no guarantee
that location has _anything_ to do with the return address of the
function, that your program owns that memory, or that it's even a
valid address.

The very fact that this joker mentions the return address shows
that s/he/it is attempting some form of malware.

As long as he writes his malware in Standard C, shouldn't we still help him?
:)

Besides, there are a couple legitimate reasons one might want to screw with
function returns in one's own code -- but the better solution is probably
setjmp()/longjmp() instead for those cases. Or perhaps having each function
return the address of the next function to be called -- I forget the term.

S

--
Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

[CBFalconer]

gh****@yahoo.com wrote:

The very fact that this joker mentions the return address shows
that s/he/it is attempting some form of malware.

The very fact that you calls Trisdale "Trollsdare" and me a joker
shows that you are a real bastard. And for your kind information
I am not attempting some form of malware.

Who is Trisdale and/or Trollsdare? If you are referring to
Trismegistus that is one thing, if you really mean Tisdale alias
Trollsdale he is a well known troll. If you can explain, in small
and understandable words, why you are trying to alter the return
address of an activated function via undefined behaviour and why
that is legitimate, I just might believe you. Probably won't
though.

Yes, I freely admit to being a real bastard about destructive
terrorists. Unlike some, I am willing for them to explain
themselves, and concede that mistakes can and have been made. Thus
you do not have to be immediately incarerated incommunicado in the
Gitmo Gulag and subjected to physical abuse and torture.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[CBFalconer]

Stephen Sprunk wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message

.... snip ...

The very fact that this joker mentions the return address shows
that s/he/it is attempting some form of malware.

As long as he writes his malware in Standard C, shouldn't we still
help him? :)

Besides, there are a couple legitimate reasons one might want to
screw with function returns in one's own code -- but the better
solution is probably setjmp()/longjmp() instead for those cases.
Or perhaps having each function return the address of the next
function to be called -- I forget the term.

The only reason of which I can conceive is building a debugger. He
shows no signs of having that capability.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[Default User]

gh****@yahoo.com wrote:

The very fact that you calls Trisdale "Trollsdare" and me a joker shows that
you are a real bastard.

The very fact that you are an idiot and a jerk shows me you need to be
plonked. So I will do so.

Brian

[Ben Pfaff]

CBFalconer <cb********@yahoo.com> writes:

Stephen Sprunk wrote:

"CBFalconer" <cb********@yahoo.com> wrote in message

The very fact that this joker mentions the return address shows
that s/he/it is attempting some form of malware.

Besides, there are a couple legitimate reasons one might want to
screw with function returns in one's own code -- but the better
solution is probably setjmp()/longjmp() instead for those cases.
Or perhaps having each function return the address of the next
function to be called -- I forget the term.

The only reason of which I can conceive is building a debugger. He
shows no signs of having that capability.

There are plenty of other reasons. For example, I could want to
test my software by injecting an error once per unique call path
to some function (say malloc()), or I could want to obtain
information about call path coverage in a test suite. In either
case, I would need to obtain the return address of the current
function and, preferably, the entire call chain.
--
"Welcome to the wonderful world of undefined behavior, where the demons
are nasal and the DeathStation users are nervous." --Daniel Fox

[ghyott]

CBF Alacnor wrote:

The only reason of which I can conceive is building a debugger. He
shows no signs of having that capability.

First,I just don't want to entangle myself in these vapid arguments but
you are a real shit.
Second,in my opinion only that programmer can write a secure code who
knows how to exploit a vulnerability in a code,so that's why I am
studying these type of codes.
I don't have any bad intentions. Also you better should not comment
about others capabilities and yes ,by Trisdale I meant Tisdale.
So,Good night and Good bye fucker!!!!