c++/5614: incorrect initialization of reference member in constructor initializer list
dwoodward@sonicblue.com
dwoodward@sonicblue.com
Wed Feb 6 08:58:00 GMT 2002
>Number: 5614
>Category: c++
>Synopsis: incorrect initialization of reference member in constructor initializer list
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: unassigned
>State: open
>Class: wrong-code
>Submitter-Id: net
>Arrival-Date: Wed Feb 06 08:36:01 PST 2002
>Closed-Date:
>Last-Modified:
>Originator: Don Woodward, SONIC|blue Fellow
>Release: gcc version 2.96 20000731 (Mandrake Linux 8.1 2.96-0.62mdk)
>Organization:
>Environment:
Mandrake Linux 8.1 on Pentium 450
>Description:
When initializing a reference member variable in a constructor initializer list, the reference gets initialized to garbage in this particular test case. This is definitely an error; the same test program works correctly on previous versions of gcc and on MS VC++.
The test case, briefly is follows (consult attached file for actual test case):
class Foo
{
public:
Foo() : m_ref( (1 == Func(&m_pInt) ? *m_pInt : *m_pInt) ) { }
private:
int * m_pInt;
int & m_ref;
int Func(int ** ppInt) { *ppInt = new int; return 1; }
};
Accessing m_ref will cause a segmentation fault.
>How-To-Repeat:
1. Compile the test program with: gcc test.cpp
2. Run a.out
3. Examine output, it should look like this:
main() pInt = 0x8051bb8
main() &rInt = 0x8051bb8
Test::Test() pInt = 0x8051bc8
Test::Test() &rInt = 0xbffff730
NOTE: the second &rInt in Test::Test() is bogus. This is the problem.
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="test.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.cpp"
I2luY2x1ZGUgPHN0ZGlvLmg+CgpjbGFzcyBUZXN0CnsKcHVibGljOgoJVGVzdCgpOwpwcml2YXRl
OgoJaW50ICogcEludDsKCWludCAmIHJJbnQ7CnByaXZhdGU6CglzdGF0aWMgaW50IEdldEludChp
bnQgKiogcHBJbnQpOwp9OwoKVGVzdDo6VGVzdCgpIDoKIHJJbnQoICgxID09IEdldEludCgmcElu
dCkgPyAqcEludCA6ICpwSW50KSApCnsKCXByaW50ZigiVGVzdDo6VGVzdCgpICBwSW50ID0gMHgl
eFxuIiwgKHVuc2lnbmVkIGludClwSW50KTsKCXByaW50ZigiVGVzdDo6VGVzdCgpICZySW50ID0g
MHgleFxuIiwgKHVuc2lnbmVkIGludCkmckludCk7Cn0KCmludApUZXN0OjpHZXRJbnQoaW50ICoq
IHBwSW50KQp7CgkqcHBJbnQgPSBuZXcgaW50OwoJcmV0dXJuIDE7Cn0KCmludAptYWluKGludCBh
cmdjLCBjaGFyICoqIGFyZ3YpCnsKCWludCAqIHBJbnQgPSBuZXcgaW50OwoJaW50ICYgckludCA9
ICpwSW50OwoJcHJpbnRmKCIgICAgICBtYWluKCkgIHBJbnQgPSAweCV4XG4iLCAodW5zaWduZWQg
aW50KXBJbnQpOwoJcHJpbnRmKCIgICAgICBtYWluKCkgJnJJbnQgPSAweCV4XG4iLCAodW5zaWdu
ZWQgaW50KSZySW50KTsKCVRlc3QgdGVzdDsKfQo=
More information about the Gcc-bugs
mailing list