Like Tree3Likes

Does the following code show undefined behaviour ?

This is a discussion on Does the following code show undefined behaviour ? within the C++ Programming forums, part of the General Programming Boards category; Code: #include<iostream> int& foo(int* x) { return *x; } int main() { int x=0; foo(&x) = 5; std::cout<<x; // x ...

  1. #1
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528

    Does the following code show undefined behaviour ?

    Code:
    #include<iostream>
    int& foo(int* x)
    {
        return *x;
    }
    
    
    int main()
    {
        int x=0;
        foo(&x) = 5;
        std::cout<<x; // x turns out to be 5
        return 0;
    }
    Is this way of making a reference from a pointer safe ?
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  2. #2
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    Well, you could create a dangling reference that way. What if I did:

    pointee& obj = foo(ptr);
    delete ptr;

    The reference is invalid.

  3. #3
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    I want to return a reference corresponding to a private member which is a pointer.
    So, as long as the object is not 'delete'd, I'm safe ?

    (I was worried about copies being made and the correct address not being written into... but that seems ok now)
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  4. #4
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by manasij7479 View Post
    Code:
    #include<iostream>
    int& foo(int* x)
    {
        return *x;
    }
    
    
    int main()
    {
        int x=0;
        foo(&x) = 5;
        std::cout<<x; // x turns out to be 5
        return 0;
    }
    Is this way of making a reference from a pointer safe ?
    Yep.

  5. #5
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    Quote Originally Posted by manasij7479 View Post
    I want to return a reference corresponding to a private member which is a pointer.
    So, as long as the object is not 'delete'd, I'm safe ?
    Yeah you understand correctly. Personally, I don't trust a design like that but.

  6. #6
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    Quote Originally Posted by whiteflags
    I don't trust a design like that but
    For linked structures, I'm doing the implementation with pointers, but the interface does not need that complication.
    The class would be easier to use that way.

    Any better(trusty ) alternative ?
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



  7. #7
    Registered User gardhr's Avatar
    Join Date
    Apr 2011
    Posts
    151
    Quote Originally Posted by whiteflags View Post
    Yeah you understand correctly. Personally, I don't trust a design like that but.
    Sometimes it is necessary, though. Say you have a member variable that may need to be "repointed" after construction. You can't simply use a reference, and reverting to pointer syntax might detract from the rest of the code. In that case such a convention might prove useful...

  8. #8
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    Just use pointers. Dangling references aren't supposed to happen so I would remove the possibility altogether.

  9. #9
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    I'd say it's perfectly fine. Returning a pointer is no better; a dangling reference is no worse than a dangling pointer, and you don't want to the implementation details to define your interface.

    However, to eliminate the possibility of dangling pointers or references, return a smart pointer.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  10. #10
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,027
    And for goodness sake, don't allow the caller to modify the value of the returned member. Return a const reference, and use a setter if it is necessary to modify it.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    The larch
    Join Date
    May 2006
    Posts
    3,573
    For linked structures, I'm doing the implementation with pointers, but the interface does not need that complication.
    The class would be easier to use that way.
    And for goodness sake, don't allow the caller to modify the value of the returned member. Return a const reference, and use a setter if it is necessary to modify it.
    Elysia, you should read the thread before making such strong claims.

    "I'm making a linked list" - "For goodness sake, make it a read-only linked list!"
    I might be wrong.

    Thank you, anon. You sure know how to recognize different types of trees from quite a long way away.
    Quoted more than 1000 times (I hope).

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Posts
    23,027
    I am referring to the example, which is a demonstration of what you should not do.
    I did read the thread. Whatever manasij wants to actually do is of no concern to me.
    If he/she posts code on the actual design, I'd offer the same advice if and only if I saw the same thing, and if it was relevant.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Registered User whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    7,762
    Quote Originally Posted by King Mir View Post
    Returning a pointer is no better
    Sure it's better. If you have a dangling pointer and the API is clear to document which operations invalidate such returned pointers, then you know when to reassign them or let them fall out of scope. At least with pointers, you have the option of reassigning them. Either way, I agree, it doesn't really matter what manasij does since you could solve the problem by documenting it. Plus, it truly depends on who can use delete. Since this is a class, it would be reasonably safe if only the class would delete the x in int& foo(int* x); ...

  14. #14
    Registered User
    Join Date
    Apr 2006
    Posts
    2,053
    To say that you should always return a pointer would be to say that vectors should not allow indexing.

    Documenting when a references, pointers, or iterators become invalid is certainly important, but depending on the use case it may be appropriate to do more to prevent undefined behavior.

    Yes, returning a reference should never be used to transfer ownership of an object.
    It is too clear and so it is hard to see.
    A dunce once searched for fire with a lighted lantern.
    Had he known what fire was,
    He could have cooked his rice much sooner.

  15. #15
    Registered User manasij7479's Avatar
    Join Date
    Feb 2011
    Location
    Kolkata@India
    Posts
    2,528
    Yes, returning a reference should never be used to transfer ownership of an object.
    Don't we have move for that...when needed ?

    I'm just returning it to provide an interface tor linked structures' referenced node(s).
    Manasij Mukherjee | gcc-4.9.2 @Arch Linux
    Slow and Steady wins the race... if and only if :
    1.None of the other participants are fast and steady.
    2.The fast and unsteady suddenly falls asleep while running !



Page 1 of 3 123 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Undefined Behaviour (Palindromic Number Finder)
    By pobri19 in forum C++ Programming
    Replies: 12
    Last Post: 09-28-2008, 05:54 AM
  2. Undefined behaviour telnet
    By stevesmithx in forum Tech Board
    Replies: 0
    Last Post: 04-22-2008, 02:41 AM
  3. bit shifting...undefined behaviour?
    By Sebastiani in forum C++ Programming
    Replies: 15
    Last Post: 11-07-2007, 02:11 PM
  4. Is this undefined behaviour?
    By caduardo21 in forum C Programming
    Replies: 4
    Last Post: 01-15-2006, 12:55 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21