what does this mean?

Discussion in 'C++' started by Michael, Sep 24, 2006.

  1. Michael

    Michael Guest

    int& mmin(const int &a, const int &b)
    {
    int c=a+b;
    return c;
    }

    ---------------

    I got confused... variable c is initialized in the function "mmin". It
    should be on the stack. After the function is done, the storage of "c"
    should be gone too...

    That does the "int &" do as a reference to a non-existing variable?

    Suprisingly, it worked with no problem...

    Anybody can explain?
    Michael, Sep 24, 2006
    #1
    1. Advertising

  2. Michael posted:

    > int& mmin(const int &a, const int &b)



    This is a function called "mmin". It returns a reference to a non-const
    int. It takes as arguments two references to const int's.


    > {
    > int c=a+b;
    > return c;



    Here you return a reference to a local variable -- the local variable will
    have been destroyed by the time the calling function gets to use it.


    > }
    >
    > ---------------
    >
    > I got confused... variable c is initialized in the function "mmin". It
    > should be on the stack. After the function is done, the storage of "c"
    > should be gone too...



    Yes you're right, "c" will have been destroyed.


    > What does the "int &" do as a reference to a non-existing variable?
    >
    > Suprisingly, it worked with no problem...
    >
    > Anybody can explain?



    The following works on my own system too:

    #include <iostream>

    int &Func()
    {
    int i = 7;
    return i;
    }

    int main()
    {
    std::cout << Func() << '\n';
    }

    The current International C++ Standard, however, does not define the
    behaviour of this program.

    The program attempts to access an object which has been destroyed.

    --

    Frederick Gotham
    Frederick Gotham, Sep 24, 2006
    #2
    1. Advertising

  3. Michael

    Pete Becker Guest

    Frederick Gotham wrote:
    >
    > The following works on my own system too:
    >


    It only works most of the time. It will fail if an interrupt comes along
    between the time that Func returns and the result is passed to the
    stream inserter. That's a very narrow window, which is why you don't see
    it happen too often. But if you run the program enough times, it will
    eventually fail.

    The point being to underscore that not showing visible symptoms is not
    the same as working correctly.

    --

    -- Pete

    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." For more information about this book, see
    www.petebecker.com/tr1book.
    Pete Becker, Sep 24, 2006
    #3
  4. Michael

    loufoque Guest

    Frederick Gotham wrote :
    > Here you return a reference to a local variable -- the local variable will
    > have been destroyed by the time the calling function gets to use it.


    Actually, no, it's UB.

    >
    loufoque, Sep 24, 2006
    #4
  5. Michael

    Rolf Magnus Guest

    Michael wrote:

    > int& mmin(const int &a, const int &b)
    > {
    > int c=a+b;
    > return c;
    > }
    >
    > ---------------
    >
    > I got confused... variable c is initialized in the function "mmin". It
    > should be on the stack.


    Standard C++ doesn't require a stack. It defines that variable to be an
    automatic one.

    > After the function is done, the storage of "c" should be gone too...


    Well, it might or might not. You can't rely on anything here. The behavior
    is undefined.

    > That does the "int &" do as a reference to a non-existing variable?


    Yes.

    > Suprisingly, it worked with no problem...
    >
    > Anybody can explain?


    Undefined behavior means that anything can happen.
    Rolf Magnus, Sep 24, 2006
    #5
  6. loufoque posted:

    >> Here you return a reference to a local variable -- the local variable
    >> will have been destroyed by the time the calling function gets to use
    >> it.

    >
    > Actually, no, it's UB.



    You sure about that? As far as I know, the behaviour of the following
    program is well-defined:

    int &Func()
    {
    int i; return i;
    }

    int main()
    {
    Func();
    }

    Similarly, I believe the following programming is also well-defined:

    int Func() { /* No return statement */ }

    int main() { Func(); }

    --

    Frederick Gotham
    Frederick Gotham, Sep 24, 2006
    #6
  7. Michael

    Kai-Uwe Bux Guest

    Frederick Gotham wrote:

    > loufoque posted:
    >
    >>> Here you return a reference to a local variable -- the local variable
    >>> will have been destroyed by the time the calling function gets to use
    >>> it.

    >>
    >> Actually, no, it's UB.

    >
    >
    > You sure about that? As far as I know, the behaviour of the following
    > program is well-defined:
    >
    > int &Func()
    > {
    > int i; return i;
    > }
    >
    > int main()
    > {
    > Func();
    > }


    I don't know about that one. But it looks fishy.


    > Similarly, I believe the following programming is also well-defined:
    >
    > int Func() { /* No return statement */ }
    >
    > int main() { Func(); }


    [6.6.3/2]
    .... Flowing off the end of a function is equivalent to a return with no
    value; this results in undefined behavior in a value-returning function.


    Best

    Kai-Uwe Bux
    Kai-Uwe Bux, Sep 25, 2006
    #7
  8. Kai-Uwe Bux posted:

    > [6.6.3/2]
    > ... Flowing off the end of a function is equivalent to a return with no
    > value; this results in undefined behavior in a value-returning function.



    Out of interest, I think it's legal in C89 so long as you don't try to access
    the return value.

    --

    Frederick Gotham
    Frederick Gotham, Sep 25, 2006
    #8
  9. Michael

    Jerry Coffin Guest

    In article <lHERg.14076$>,
    says...
    > Kai-Uwe Bux posted:
    >
    > > [6.6.3/2]
    > > ... Flowing off the end of a function is equivalent to a return with no
    > > value; this results in undefined behavior in a value-returning function.

    >
    >
    > Out of interest, I think it's legal in C89 so long as you don't try to access
    > the return value.


    That's correct (section 6.6.6.4): "If a return statement without an
    expression is executed, and the value of the function call is used by
    the caller, the behavior is undefined. Reaching the } that terminates a
    function is equivalent to executing a return statement without an
    expression."

    In C99, however, the rule changes to be like in C++ (section 6.8.6.4/1,
    a constraint on the return statement): "A return statement without an
    expression shall appear only in a function whose return type is void."

    --
    Later,
    Jerry.

    The universe is a figment of its own imagination.
    Jerry Coffin, Sep 25, 2006
    #9
  10. Jerry Coffin posted:

    > In C99, however, the rule changes to be like in C++ (section 6.8.6.4/1,
    > a constraint on the return statement): "A return statement without an
    > expression shall appear only in a function whose return type is void."



    I read that to mean that you can't have:

    int Func() { return; }

    It doesn't suggest to me that the following is broken:

    int Func() {}

    --

    Frederick Gotham
    Frederick Gotham, Sep 27, 2006
    #10
  11. Frederick Gotham wrote:
    > Jerry Coffin posted:
    >
    >> In C99, however, the rule changes to be like in C++ (section
    >> 6.8.6.4/1, a constraint on the return statement): "A return
    >> statement without an expression shall appear only in a function
    >> whose return type is void."

    >
    >
    > I read that to mean that you can't have:
    >
    > int Func() { return; }
    >
    > It doesn't suggest to me that the following is broken:
    >
    > int Func() {}


    Clarification: "broken" most likely means "ill-formed" here.
    Victor Bazarov, Sep 27, 2006
    #11
  12. Victor Bazarov posted:

    >> It doesn't suggest to me that the following is broken:
    >>
    >> int Func() {}

    >
    > Clarification: "broken" most likely means "ill-formed" here.



    I use the term, "broken", when I've to pause for more than two seconds to
    consider whether it's "undefined behaviour" or "ill-formed"... it's a blanket
    term!

    --

    Frederick Gotham
    Frederick Gotham, Sep 27, 2006
    #12
  13. Frederick Gotham wrote:
    > Victor Bazarov posted:
    >
    >>> It doesn't suggest to me that the following is broken:
    >>>
    >>> int Func() {}

    >>
    >> Clarification: "broken" most likely means "ill-formed" here.

    >
    >
    > I use the term, "broken", when I've to pause for more than two
    > seconds to consider whether it's "undefined behaviour" or
    > "ill-formed"... it's a blanket term!


    Trying to pull some wool over our eyes, eh?

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Sep 27, 2006
    #13
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pratip Mukherjee

    Help: what does this VHDL code mean?

    Pratip Mukherjee, Jun 22, 2005, in forum: VHDL
    Replies:
    16
    Views:
    1,259
    Kim Enkovaara
    Jun 27, 2005
  2. methi
    Replies:
    1
    Views:
    824
    info_
    Jun 23, 2005
  3. Li Ma
    Replies:
    1
    Views:
    2,264
    Roedy Green
    Mar 9, 2009
  4. Rahul
    Replies:
    4
    Views:
    548
    Robert Kern
    Apr 7, 2009
  5. C Barrington-Leigh
    Replies:
    1
    Views:
    1,178
    Tim Leslie
    Sep 10, 2010
Loading...

Share This Page