function return pointer of int?

[Davy]

Hi all,

I am writing a function, which return the pointer of the int. But it
seems to be wrong. Any suggestion?

int * get_p_t(int t) {
return &t;
}

int main()
{
printf("v1\n");
int t = 5;
int * p_t[2];

p_t[0] = &t; // right
p_t[1] = get_p_t(t); //wrong

return 0;
}

Best regards,
Davy

 

[Ian Collins]

Hi all,

I am writing a function, which return the pointer of the int. But it
seems to be wrong. Any suggestion?

int * get_p_t(int t) {
return &t;
}

t is effectively a local variable in get_p_t. So the address you return
will be invalid after the function returns.

 

[Davy]

t is effectively a local variable in get_p_t.  So the address you return
will be invalid after the function returns.

Hi Ian, thank you,

But how can I get the address of t in the main() scope, if I want to
use function?

 

[Ian Collins]

Hi Ian, thank you,

But how can I get the address of t in the main() scope, if I want to
use function?

You can't. You get the address of where t was.

 

[DJ Dharme]

You can't.  You get the address of where t was.

Still he can get a reference or a pointer to t as the input parameter
and return a valid pointer.

 

[Marcel Müller]

Hi

But how can I get the address of t in the main() scope, if I want to
use function?

int * get_p_t(int & t) {
return &t;
}

will do the job, but it still makes little sense since you stil may
receive a local address from the caller. At least it should be well
documented the the argument to get_p_t has to be valid at least as long
as the return value is used.


[Only posted to the c++ group]


Marcel

 

[Ian Collins]

Still he can get a reference or a pointer to t as the input parameter
and return a valid pointer.

Do what?

 

[Nick Keighley]

Hi Ian, thank you,

But how can I get the address of t in the main() scope, if I want to
use function?

as Ian Collins said "you can't".

Why do you want to do this? I'm not being awkward if you explain
your larger problem, the context in which you want the address of t
we might be able to suggest a workaround.

int main (void)
{
printf("v1\n");
int t = 5;
int * p_t[2];

p_t[0] = &t;
p_t[1] = get_p_t(t);

/*** you have the address of t by using &t.
why do you want a function to do this? */

return 0;
}

 

[vippstar]

Still he can get a reference or a pointer to t as the input parameter
and return a valid pointer.

Please don't quote signatures. (the text after --)
Also, no, he can't. I think his function is valid, ie this code is
valid:

int *foo(int i) { return &i; }

However even evaluating foo(anything) invokes undefined behavior,
since the object pointed to by the pointer is over its lifetime, and
the pointer becomes indeterminate. (either unspecified value or trap
representation)

 

[James Kuyper]

Hi Ian, thank you,

But how can I get the address of t in the main() scope, if I want to
use function?

int * get_p_int(int *pt) { return pt;}

int main(void)
{
int t;
int *p = get_p_int(&t);


Of course, this is pretty pointless; get_p_int(&t) doesn't get you
anything that &t doesn't already get you. So you might as well writer

int *p = &t;

So, what is the real problem you're trying to solve?

 

[Richard Herring]

int * get_p_int(int *pt) { return pt;}

int main(void)
{
int t;
int *p = get_p_int(&t);


Of course, this is pretty pointless; get_p_int(&t) doesn't get you
anything that &t doesn't already get you. So you might as well writer

int *p = &t;

So, what is the real problem you're trying to solve?

Understanding the difference between C++ and C? Note the crosspost.

 

[James Kanze]

But how can I get the address of t in the main() scope, if I
want to use function?

Didn't you read what Ian wrote? t doesn't exist except when
you're executing get_p_t. And there's obviously no way to get
the address of something which doesn't exist.

 

[James Kuyper]

Understanding the difference between C++ and C? Note the crosspost.

You're right, I didn't notice the cross-post. There is indeed a C++
solution using references:

int *get_p_int(int &t) { return &t;}

Because of the syntactic sugar of references, the C++ version appears
marginally less pointless than the C version, but I think that's mostly
an illusion - the machine code generated for either version should be
functionally equivalent. However, precisely because of the cross-post, I
think that use of C++ references would be inappropriate; the cross-post
implies a desire for a solution that works in either language.

 

[Kenny McCormack]

Didn't you read what Ian wrote? t doesn't exist except when
you're executing get_p_t.
True.

And there's obviously no way to get
the address of something which doesn't exist.

Not true. The Munsters don't exist, but their address is "1313
Mockingbird Lane". So, it is possible to have the address of something
that doesn't exist. De-referencing such an address does, of course,
lead to undefined behavior.

 

[Keith Thompson]

Also, no, he can't. I think his function is valid, ie this code is
valid:

int *foo(int i) { return &i; }

However even evaluating foo(anything) invokes undefined behavior,
since the object pointed to by the pointer is over its lifetime, and
the pointer becomes indeterminate. (either unspecified value or trap
representation)

It's "valid" only in the narrow sense that it doesn't violate any
constraint or syntax rule. But "valid" isn't a word I'd apply to a
function that can't be called without invoking undefined behavior.

 

[James Kanze]

...

Not true. The Munsters don't exist, but their address is
"1313 Mockingbird Lane".

Only in the imaginary world where they exist.

So, it is possible to have the address of something that
doesn't exist. De-referencing such an address does, of
course, lead to undefined behavior.

First, you can't have an address of something that doesn't
exist. You can perhaps have a pointer whose bit pattern
corresponds to the address where it was, but it's no longer a
valid address, and even copying it is undefined behavior.

 

[Puppet_Sock]

Please don't quote signatures. (the text after --)
Also, no, he can't. I think his function is valid, ie this code is
valid:

int *foo(int i) { return &i; }

However even evaluating foo(anything) invokes undefined behavior,
since the object pointed to by the pointer is over its lifetime, and
the pointer becomes indeterminate. (either unspecified value or trap
representation)

It only becomes undefined if you try to deref the
pointer that gets returned, because it's a pointer
to a local variable, which has gone out of scope
by the time foo returns. There is no problem with
taking the address, or passing the address around.
But if you try to manipulate things through that
address, you open the gates of undefined.
Socks

 

[Keith Thompson]

On Nov 5, 4:26 am, (e-mail address removed) wrote: [...]

int *foo(int i) { return &i; }

However even evaluating foo(anything) invokes undefined behavior,
since the object pointed to by the pointer is over its lifetime, and
the pointer becomes indeterminate. (either unspecified value or trap
representation)

It only becomes undefined if you try to deref the
pointer that gets returned, because it's a pointer
to a local variable, which has gone out of scope
by the time foo returns. There is no problem with
taking the address, or passing the address around.
But if you try to manipulate things through that
address, you open the gates of undefined.

(Ok, whose sock-puppet are you?)

You're mistaken. If you have a pointer to an object, and that object
then ceases to exists, then the pointer value becomes indeterminate,
and any attempt to evaluate the pointer invokes undefined behavior.

For example:

int *p = malloc(sizeof *p);
assert(p != NULL); /* just for this example */
free(p);
p; /* undefined behavior */

On most implementations, nothing bad will actually happen; that's just
one possible manifestation of undefined behavior.

 

[jameskuyper]

On Nov 5, 4:26�am, (e-mail address removed) wrote: ....

It only becomes undefined if you try to deref the
pointer that gets returned, because it's a pointer
to a local variable, which has gone out of scope
by the time foo returns. There is no problem with
taking the address, or passing the address around.
But if you try to manipulate things through that
address, you open the gates of undefined.

Dereferencing the pointer is not the only way the behavior can be
undefined.

6.2.4p2: "The value of a pointer becomes indeterminate when the object
it points to reaches the end of its lifetime."

The lifetime of 't' has already ended by the time the function has
returned.

The definition of "indeterminate value" is given in 3.17.2p1: "either
an unspecified value or a trap representation".

Because the value returned by the function could be a trap
representation, any attempt to store it in an object will also have
undefined behavior.

Using the value without storing it in a pointer object would seem to
be safe, but virtually every operation you can perform on a non-null
pointer value other than storing it somewhere, is defined in terms of
the object that it points at. As a result, since no such object exists
any longer, the behavior is implicitly undefined, by reason of the
absence of an applicable definition of the behavior. The standard
explicitly allows for behavior to be implicitly undefined.

 

[Harald van Dijk]

Please don't quote signatures. (the text after --) Also, no, he can't. I
think his function is valid, ie this code is valid:

int *foo(int i) { return &i; }

However even evaluating foo(anything) invokes undefined behavior, since
the object pointed to by the pointer is over its lifetime, and the
pointer becomes indeterminate. (either unspecified value or trap
representation)

You are allowed to call foo. You are even allowed to use its return value
in limited ways (such as comparisons). You are not allowed to store foo's
result in an object, or dereference it.

The behaviour dealing with trap representations is only undefined if you
store them in an object ("produced by a side effect that modifies all or
any part of the object by an lvalue expression that does not have
character type"), or read them from an object ("read by an lvalue
expression that does not have character type"). In this code, if you call
foo and discard its result, the return value is never stored in or read
from an object.

Actually, I'm not sure how the return value could be a trap representation
at all, since it's a value, and the concept of trap representations
applies to objects, but 6.3.2.2p5 (conversions of integers to pointers) is
a clear example of when a non-lvalue expression may explicitly be a trap
representation.