OTHER: fix c++ client dangling reference

[trofi]

On #xmm2 Chewi reported c++/tut7 to be broken at start:

GLib-WARNING **: glib-2.56.2/glib/giounix.c:410
Error while getting flags for FD: Bad file descriptor (9)

valgrind shows the problem as read of uninitialized data:

$ valgrind ./tut7

==32268== Conditional jump or move depends on uninitialised value(s)
==32268==    at 0x49DC36B: xmmsc_mainloop_gmain_init (xmmsclient-glib.c:80)
==32268==    by 0x49E11BE: Xmms::GMainloop::GMainloop(xmmsc_connection_St*) (xmmsclient++-glib.cpp:11)
==32268==    by 0x10C64D: main (in /home/slyfox/dev/git/xmms2-devel/doc/tutorial/c++/tut7)
==32268==  Uninitialised value was created by a stack allocation
==32268==    at 0x49E119A: Xmms::GMainloop::GMainloop(xmmsc_connection_St*) (xmmsclient++-glib.cpp:8)

This happens due to use of dangling C++ reference to stack variable:

// somewhere in src/include/xmmsclient/xmmsclient++/mainloop.h
class MainloopInterface {
    MainloopInterface( xmmsc_connection_t* conn ) :
        running_( false ), conn_( conn ) { }
  protected:
    bool running_;
    xmmsc_connection_t*& conn_;
}

Note: conn_ refers to dangling local variable of
MainloopInterface::MainloopInterface constructor.

The fix is to pass through pointer reference.
MainLoop::MainLoop() already does it.

Reported-by: James Le Cuirot
Signed-off-by: Sergei Trofimovich slyfox@gentoo.org

[zharf]

I'm actually a little too tired to think right now but at least GMainloop constructor also needs to have this change as well...

[trofi]

Good catch! That xmmc_connection_t *& API is really hard to use right :) I'll see if client can switch it to xmmc_connection_t * and not allow the pointer to change underneath.

[trofi]

Converting to draft as I think it introduces dangling reference to a temporary on initial object creation. I'll spend some time tracing through lifetimes more explicitly and redo.