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

[Harald van =?UTF-8?b?RMSzaw==?=]

On Wed, 05 Nov 2008 18:17:51 +0000, Harald van Dijk wrote:

On Wed, 05 Nov 2008 01:26:57 -0800, vippstar wrote:

>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.

I would like to add that when I posted this, I hadn't noticed the cross-
post. What I said applies to C99; C90 is different here. I do not know
whether C++ in its current form follows C90, C99, or has entirely
different rules regarding indeterminate values.

[James Kanze]

On Nov 5, 7:17Â*pm, Harald van Dijk <true...@gmail. comwrote:

On Wed, 05 Nov 2008 01:26:57 -0800, vippstar wrote:

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).

Are you sure? It's certainly not the case in C++, and I didn't
think it was the case in C; any use of the pointers value
(lvalue to rvalue conversion) is undefined behavior, so
comparisons are out.

If the invalid pointer is an lvalue expression, you can do
anything with it that doesn't require an lvalue to rvalue
conversion. For example, take its address, or in C++, bind it
to a reference. Which means that you can also memcpy and memcmp
it. (In the actual example, of course, the pointer isn't an
lvalue, so this is irrelevant.)

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.

Is this a change in C99? It's not the case in C++, nor was it
the case in C90.

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.

It looks like the attempts to clean up a rather vague concept
accidentally went too far. (In C++, this wouldn't cause a
problem, because you return a temporary object, and of course,
this object can have a trapping representation, in which case,
you trap. Not sure about C in this regard.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Harald van =?UTF-8?b?RMSzaw==?=]

On Wed, 05 Nov 2008 10:55:16 -0800, James Kanze wrote:

On Nov 5, 7:17Â*pm, Harald van Dijk <true...@gmail. comwrote:

>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.

Is this a change in C99? It's not the case in C++, nor was it the case
in C90.

Yes, this is what 6.2.6.1p5 says:
"Certain object representations need not represent a value of the object
type. If the stored value of an object has such a representation and is
read by an lvalue expression that does not have character type, the
behavior is undefined. If such a representation is produced by a side
effect that modifies all or any part of the object by an lvalue
expression that does not have character type, the behavior is
undefined.[*] Such a representation is called a trap representation. "

C99 has dropped C90's wording for reading indeterminate values, and
replaced it with this.

Thanks for a bit of info on C++'s approach to this.

[Phil Carmody]

Keith Thompson <ks***@mib.orgw rites:

Puppet_Sock <pu*********@ho tmail.comwrites :

>On Nov 5, 4:26*am, vipps...@gmail. com 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
representatio n)

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.

What about not doing anything with it?

foo(0);

It's not being assigned to anything, compared to anything, computed
with, dereferenced, or basically anything that could be said to be
"evaluating " the pointer?

Phil
--
We must respect the other fellow's religion, but only in the sense and to the
extent that we respect his theory that his wife is beautiful and his children
smart. -- Henry Louis Mencken (1880-1956), American editor and critic

[Keith Thompson]

Phil Carmody <th************ *****@yahoo.co. ukwrites:

Keith Thompson <ks***@mib.orgw rites:

>Puppet_Sock <pu*********@ho tmail.comwrites :

>>On Nov 5, 4:26*am, vipps...@gmail. com 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
representati on)

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.

What about not doing anything with it?

foo(0);

It's not being assigned to anything, compared to anything, computed
with, dereferenced, or basically anything that could be said to be
"evaluating " the pointer?

When an expression statement is executed, the expression is evaluated
and its result is discarded. An implementation might reasonably store
the result in an address register; the act of storing an invalid
address in an address register might cause a trap.

But Harald made a very interesting point. The pointer value returned
by foo is indeterminate, meaning that it's either an unspecified value
or a trap representation. But a trap representation is not a value.
His argument is that there's no representation (at least as far as the
language semantics are concerned) until and unless the value is stored
in an object.

On the other hand, this means that the standard's definition of an
indeterminate *value* as either an unspecified value or a trap
*representation * doesn't make a whole lot of sense.

I'm not sure how this should be resolved.

--
Keith Thompson (The_Other_Keit h) 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"

[baichuan0798]

On 11ÔÂ5ÈÕ, ÏÂÎç3ʱ06·Ö, Davy <zhushe...@gmai l.com>wrote:

On Nov 5, 2:49 pm, Ian Collins <[e-mail] mwrote:

Davy wrote:

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.

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- Òþ²Ø±»ÒýÓÃÎÄ×Ö -

- ÏÔʾÒýÓõÄÎÄ×Ö -

void *fun(int i)
{
void *p = &i;
p += (1<<5) + 4;

return p;
}

[Barry Schwarz]

On Wed, 5 Nov 2008 22:30:03 -0800 (PST), ba**********@16 3.com wrote:

>On 11??5??, ????3??06??, Davy <zhushe...@gmai l.comwrote:

>On Nov 5, 2:49 pm, Ian Collins <[e-mail] mwrote:

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

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- ?????????????? -

- ?????????????? -

void *fun(int i)
{
void *p = &i;
p += (1<<5) + 4;

return p;
}

What do you think this accomplishes?

Your first executable statement contains a constraint violation. If
you ignore that (some compilers do as an extension), it invokes
undefined behavior if sizeof(int) < 36. If you have a system with
really large int, then the value returned still becomes indeterminate
as soon as the function returns.

--
Remove del for email

[James Kanze]

On Nov 6, 7:39 am, Barry Schwarz <schwa...@dqel. comwrote:

On Wed, 5 Nov 2008 22:30:03 -0800 (PST), baichuan0...@16 3.com wrote:

[...]

void *fun(int i)
{
void *p = &i;
p += (1<<5) + 4;

return p;
}

What do you think this accomplishes?

Your first executable statement contains a constraint violation.

I'm not sure what you mean by the "first executable statement".
The definition of p (with its initialization) definitely
generates executable code, and is executed. And there's no
problem with this statement; it is legal and well defined, and
must work in any implementation.

The second statement, of coruse, is ill formed. Pointer
arithmetic is illegal on pointers to void. This is a
constraint violation, which requires a diagnostic.

If you ignore that (some compilers do as an extension), it
invokes undefined behavior if sizeof(int) < 36.

If you have invoked the compiler in a non-conformant mode, what
it does is defined by the compler. If a compiler accepts the
second statement above, you can no longer argue about the code
with regards to the language. For that matter, technically,
once the compiler has issued the diagnostic, it has fulfilled
its obligation, and the rest is undefined behavior. (QoI
issues, of course, introduce additional constraints, but as far
as the standard is concerned, a compiler that reformats your
hard disk anytime you try to compile an ill-formed program is
compliant. The compiler could even document that it's
diagnostic message was to turn on the light of the hard disk
drive for an indeterminate time---I don't think that the
standard formally requires the diagnostic to be text.)

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kuyper]

Keith Thompson wrote:
....

But Harald made a very interesting point. The pointer value returned
by foo is indeterminate, meaning that it's either an unspecified value
or a trap representation. But a trap representation is not a value.
His argument is that there's no representation (at least as far as the
language semantics are concerned) until and unless the value is stored
in an object.

More to the point, the only cases associated with trap representations
where the C standard explicitly says the behavior is undefined are the
creation of a trap representation in an object by any method other than
use of an lvalue of character type, or by attempting to access the value
of an object that already contains a trap representation.

On the other hand, this means that the standard's definition of an
indeterminate *value* as either an unspecified value or a trap
*representation * doesn't make a whole lot of sense.

I think that the fundamental problem was the decision of the C committee
to define an indeterminate "value" as including, as one possibility, a
trap "representation ". It should probably have been called an
"indetermin ate representation" , but that would have required rewriting
every place in the standard that currently uses "indetermin ate value",
and the rewrite would be substantially clumsier than the current wording.

In particular, such a change would make it more complicated to describe
what is going wrong in this particular program: returning a pointer from
a function that becomes invalid precisely because of the fact the
function has returned. Maybe we also need the concept of a "trap value",
distinct from the idea of a "trap representation" ?

[Ben Bacarisse]

James Kanze <ja*********@gm ail.comwrites:

On Nov 6, 7:39 am, Barry Schwarz <schwa...@dqel. comwrote:

>On Wed, 5 Nov 2008 22:30:03 -0800 (PST), baichuan0...@16 3.com wrote:

[...]

>void *fun(int i)
{
void *p = &i;
p += (1<<5) + 4;

return p;
}

>What do you think this accomplishes?

>Your first executable statement contains a constraint violation.

I'm not sure what you mean by the "first executable statement".
The definition of p (with its initialization) definitely
generates executable code, and is executed. And there's no
problem with this statement; it is legal and well defined, and
must work in any implementation.

The cross-post is confusing matters (as always!).

In C there is a clear distinction between declarations and statements,
both in the formal syntax as well as in the less formal text of the
standard, so "the first statement" refers unambiguously to the
increment of p (and the extra "executable " is redundant). In C++, as
you know, there is a "declaratio n statement" so the distinction is
lost. Barry is presumably assuming the code is C.

--
Ben.