I was looking through the standard trying to find anything about
whether the following is defined or undefined behaviour:

int* f()
{
 int i;
 return &i; //naughty, but illegal in itself?
}

int main()
{
 f(); //I assume this is legal, right?

 int* p = f(); //lvalue to rvalue conversion on pointer to
                              //object whose lifetime has ended.
 int* q = p; //lvalue to rvalue conversion on pointer to
                             //object whose lifetime has ended.

 int* r;
 int* s = r; //lvalue to rvalue conversion on uninitialized
                            //pointer
}

3.7.3.2 p4 talks about deallocated storage and invalid pointers, but
nowhere does it say that the f(), p, q or r as above are "invalid". (I
searched the whole language part for the word invalid).

What's the story?

Tom

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Tom wrote:
>
> I was looking through the standard trying to find anything about
> whether the following is defined or undefined behaviour:
>
> int* f()
> {
>         int i;
>         return &i; //naughty, but illegal in itself?

No, i is an lvalue, you can apply & to it.  It's still alive until
the function returns.


>         f(); //I assume this is legal, right?

Looks good to me.

>
>         int* p = f(); //lvalue to rvalue conversion on pointer to
>                               //object whose lifetime has ended.

What lvalue to rvalue conversion?  The return value is already an rvalue.

> 3.7.3.2 p4 talks about deallocated storage and invalid pointers, but
> nowhere does it say that the f(), p, q or r as above are "invalid". (I
> searched the whole language part for the word invalid).

3.7.3.2 doesn't seem to haveanything to do with this.  It's talking about
things that have been passed to "delete".  I'm not able to find any mention
of pointers to autos that have ceased to exist.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]

Hi,

"Tom" <the_wid@my-deja.com> schrieb im Newsbeitrag
news:3a8ca094.12966775@news.ntlworld.com...
> I was looking through the standard trying to find anything about
> whether the following is defined or undefined behaviour:
>
> int* f()
> {
> int i;
> return &i; //naughty, but illegal in itself?
> }
> [...]

as you recognize, you returned a pointer to an object that doesn't exists
anymore. It's not illegal, but the behaviour is undefined. Sometimes it
seems to work because the memory location for the local object may contain
the original value for i. But if you program for example under a realtime
os, thats not guaranteed. If the system dispatches the thread, the memory
location may be changed. So you should use always the following methode:

int f()
{
 AnyClass i;
....
return i;
}

int main()
{
  AnyClass X;
  X = f();
  ...
}

In the example above, I've changed the type from int to a class to
demonstrated what happens. First you create an Objekt of typ AnyClass X.
Then you call f(), which creates another object i. Then the funktion f()
exits. Now a temporary object of AnyClass will be created by the compiler
(because it must return someone) which will be initialized by i (copy-ctor
is called). After returning from f(), this local object is assigned to X
(operator = called in context of X).

HTH

--
Wolfgang Schr   der
e-mail: cppkurs@talknet.de
Home: www.talknet.de/~cppkurs

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]
[ Note that the FAQ URL has changed!  Please update your bookmarks.     ]