GCC 4.8 with GNU STL produces bad code for std::string constructor?

Question

So a bit of C++ code:

void func( const std::string& theString )
{
    std::string theString( theString );
    theString += " more string";
    std::cout << theString;
}

which compiles fine with GCC 4.8 and VS 2013. From my C++ knowledge, the code is okay with a local variable theString being brought into scope which then hides theString from the function argument. At the point of theString construction, the only theString in scope is the function argument which is passed to the std::string constructor. The constructed std::string is then named theString which comes into scope and is theString used later in the code. Phew!

However, GCC seems to act like theString passed to the std::string constructor is the local theString (which hasn't been constructed yet) causing the compiled program to crash. With VS 2013 the code compiles and runs fine.

So,

Is my code correct? Or am I doing something outside spec which means the GCC behaviour is undefined.
Is this a bug in GCC?

At the very least, your code is awful. You should never code like that, since it is unreadable (for humans). — Basile Starynkevitch, Nov 05 '14 at 13:21
1. No. 2. No. You are initializing a string with its (uninitialized) self. — juanchopanza, Nov 05 '14 at 13:25
So the bug is more likely inside VS2013, if there is one. But your code is wrong. — Basile Starynkevitch, Nov 05 '14 at 13:27
@BasileStarynkevitch Although if it is UB, then the VS2013 behaviour is "ok". — juanchopanza, Nov 05 '14 at 13:28
@BasileStarynkevitch Agreed, it's horrible stuff. Sadly it can crop up and knowing what is "right" by the compiler is important :) btw Thanks for all the responses! — user2746401, Nov 05 '14 at 13:56
p.s. is there a warning I can turn on to detect this misuse? — user2746401, Nov 05 '14 at 14:46
Your `cout` line has `tsString` instead of `theString`, is that a typo? — Nate Eldredge, Nov 05 '14 at 15:44
When I compile this with GCC 4.8.2 I get `error: declaration of ‘std::string theString’ shadows a parameter`. No extra options needed. — Nate Eldredge, Nov 05 '14 at 15:46
possible duplicate of [Using newly declared variable in initialization (int x = x+1)?](http://stackoverflow.com/questions/9820027/using-newly-declared-variable-in-initialization-int-x-x1) — nobody, Nov 05 '14 at 19:48
@AndrewMedico the proposed duplicate really does not cover this case, which I describe in my answer. The other answers are very superficial to the point of being unhelpful in actually understanding what is going on. — Shafik Yaghmour, Nov 10 '14 at 15:43

score 30 · Accepted Answer · answered Nov 05 '14 at 13:26

30

No, your code is invalid.

According to the C++ Standard (3.3.2 Point of declaration)

1 The point of declaration for a name is immediately after its complete declarator (Clause 8) and before its initializer (if any), except as noted below.

[ Example:
int x = 12;
{ int x = x; }

Here the second x is initialized with its own (indeterminate) value. —end example ]

And (3.3.3 Block scope, #2)

A parameter name shall not be redeclared in the outermost block of the function definition nor in the outermost block of any handler associated with a function-try-block.

answered Nov 05 '14 at 13:26

Vlad from Moscow

301,070
26
186
335

2

The canonical questions for that example in `3.3.2` are: for C++11 [Does initialization entail lvalue-to-rvalue conversion? Is `int x = x;` UB?](http://stackoverflow.com/q/14935722/1708801) and for C++14 [Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++1y?](http://stackoverflow.com/q/23415661/1708801) – Shafik Yaghmour Nov 05 '14 at 19:40

score 14 · Answer 2 · edited May 23 '17 at 10:29

14

This is undefined behaviour in C++. paxdiablo quotes the C++03 standard:

The point of declaration for a name is immediately after its complete declarator (clause 8) and before its initializer (if any) ...

Example:
int x = 12;
{ int x = x; }
Here the second x is initialized with its own (indeterminate) value.

edited May 23 '17 at 10:29

Community

1
1

answered Nov 05 '14 at 13:24

vz0

32,345
7
44
77

score 2 · Answer 3 · edited May 23 '17 at 11:55

Although the current answers are basically correct, this is undefined behavior because you are using an indeterminate value the details are a bit more involved. For primitive types I believe either Does initialization entail lvalue-to-rvalue conversion? Is int x = x; UB? or Has C++ standard changed with respect to the use of indeterminate values and undefined behavior in C++1y? provide sufficient detail to understand why the behavior is undefined.

For a user defined type though I don't think they fill in enough of the details. We can see from this rather old but relevant defect report 63: Initialization of class from self which asks:

And if so, what is the semantics of the self-initialization of UDT?

and provides an example in which only the reference and the address is taken of the class under construction and the answer says:

3.8 basic.life paragraph 6 indicates that the references here are valid. It's permitted to take the address of a class object before it is fully initialized, and it's permitted to pass it as an argument to a reference parameter as long as the reference can bind directly.

It is referring to section 3.8 Object lifetime because the object is under construction and its storage has been allocated but it lifetime has not began because its initialization is not complete.

If we look at paragraph 6 from section 3.8 it says (emphasis mine):

Similarly, before the lifetime of an object has started but after the storage which the object will occupy has been allocated or, after the lifetime of an object has ended and before the storage which the object occupied is reused or released, any glvalue that refers to the original object may be used but only in limited ways. For an object under construction or destruction, see 12.7. Otherwise, such a glvalue refers to allocated storage (3.7.4.2), and using the properties of the glvalue that do not depend on its value is well-defined. The program has undefined behavior if:

and includes:

the glvalue is used to access a non-static data member or call a non-static member function of the object,

So before the initialization is complete we can not take the value of a non-static data member which clearly will be required during copy construction of a std::string.

GCC 4.8 with GNU STL produces bad code for std::string constructor?

3 Answers3

Linked