[Bug c++/101850] New: Initialising a std::string variable to itself does not fail at compile time, but throws std::bad_alloc at run time

[Bug c++/101850] New: Initialising a std::string variable to itself does not fail at compile time, but throws std::bad_alloc at run time

[prasantabehera at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

            Bug ID: 101850
           Summary: Initialising a std::string variable to itself does not
                    fail at compile time, but throws std::bad_alloc at run
                    time
           Product: gcc
           Version: 8.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: prasantabehera at hotmail dot com
  Target Milestone: ---

Version info:
=============
~$ g++ --version
g++ (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

~$ gcc --version
gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Sample Program:
===============
~$ cat t.cpp
#include <string>

int main() {
  std::string s = s;
  return 0;
}

Problem Description:
====================
The above program tries to initialise a string with itself which is wrong!
However g++ does not show any compile time error, but the resulting binary
fails at run time throwing std::bad_alloc as shown below.

~$ g++ t.cpp
~$ ./a.out
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
Aborted (core dumped)

gcc however shows a link time error which is slightly better.

~$ gcc t.cpp
/tmp/cc30YkgH.o: In function `main':
t.cpp:(.text+0x27): undefined reference to `std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char>
>::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>,
std::allocator<char> > const&)'
t.cpp:(.text+0x38): undefined reference to `std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> >::~basic_string()'
collect2: error: ld returned 1 exit status

I think the coding error should be caught at the compile time by g++. 

Also, the problem is same with any generic C++ class/struct:

#include <string>

struct M {
  std::string s;
};

int main() {
  // std::string s = s;
  M m = m;
  return 0;
}

Also checked with g++ version 7.5.0, to see the same behavior.

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
In GCC 11+ we start to warn about this code with -W -Wall:
<source>: In function 'int main()':
<source>:5:19: warning: 's' may be used uninitialized [-Wmaybe-uninitialized]
    5 |   std::string s = s;
      |                   ^

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |48829

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
See PR 48829 also.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48829
[Bug 48829] g++ no warning initializing a variable using itself

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Prasanta Behera from comment #0)
> Version info:
> =============
> ~$ g++ --version
> g++ (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> ~$ gcc --version
> gcc (Ubuntu 8.4.0-1ubuntu1~18.04) 8.4.0
> Copyright (C) 2018 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Sample Program:
> ===============
> ~$ cat t.cpp
> #include <string>
> 
> int main() {
>   std::string s = s;
>   return 0;
> }
> 
> Problem Description:
> ====================
> The above program tries to initialise a string with itself which is wrong!

Yes, it's undefined behaviour.

> However g++ does not show any compile time error, but the resulting binary
> fails at run time throwing std::bad_alloc as shown below.

That's one way that undefined behaviour can manifest itself. You cannot expect
to get a compile time error for all cases of undefined behaviour, that's why
it's undefined.

> ~$ g++ t.cpp
> ~$ ./a.out
> terminate called after throwing an instance of 'std::bad_alloc'
>   what():  std::bad_alloc
> Aborted (core dumped)
> 
> gcc however shows a link time error which is slightly better.
> 
> ~$ gcc t.cpp
> /tmp/cc30YkgH.o: In function `main':
> t.cpp:(.text+0x27): undefined reference to `std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char>
> >::basic_string(std::__cxx11::basic_string<char, std::char_traits<char>,
> std::allocator<char> > const&)'
> t.cpp:(.text+0x38): undefined reference to `std::__cxx11::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::~basic_string()'
> collect2: error: ld returned 1 exit status

No, this is just because gcc doesn't link to the C++ runtime which is needed to
use std::string. You will get the same link error for a correct program, it has
absolutely nothing to do with the bug in your code.

> I think the coding error should be caught at the compile time by g++. 

It is caught, by a warning.

In the general case, turning all such mistakes into errors is impossible:

const std::string& func(const std::string&);

std::string s = func(s);

The compiler cannot know whether func has undefined behaviour or not. It could
be defined like this, which would be OK:

const std::string& func(const std::string& /*unused*/) {
  static std::string str = "a string with static storage duration";
}

Or it could be defined like this, which would be equivalent to your example:

const std::string& func(const std::string& s) {
  return s;
}

tl;dr it is not reasonable to expect to always get a compile time error for
undefined behaviour, it's the programmer's responsibility to avoid undefined
behaviour. COmpiler warnings can help, if you enable them and pay attention to
them.

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

[prasantabehera at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

--- Comment #4 from Prasanta Behera <prasantabehera at hotmail dot com> ---
FWIW clang++ does produce these warnings:

~$ cat t.cpp 
#include <string>

class M {
  std::string s;

public:
  M(std::string t) : s(t) {}
};

int main() {
  std::string s = s;
  M m = m;
  return 0;
}
~$ clang++ t.cpp
t.cpp:11:19: warning: variable 's' is uninitialized when used within its own
initialization [-Wuninitialized]
  std::string s = s;
              ~   ^
t.cpp:12:9: warning: variable 'm' is uninitialized when used within its own
initialization [-Wuninitialized]
  M m = m;
    ~   ^
2 warnings generated.
~$ clang++ --version
clang version 10.0.0-4ubuntu1 
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Similar warnings for g++ too will help a lot!

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=18635

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Did you read comment 1?

GCC already warns. You're using GCC 8.4.0 which is old and unsupported.

[Bug c++/101850] Initialising a struct/class variable to itself does not fail at compile time (but throws std::bad_alloc at run time, as expected)

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101850

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
extern "C" char* strdup(const char*);
extern "C" void free(void*);

namespace std 
{
  struct string
  {
    string() { }
    string(string const& s) : data(strdup(s.data)) { }
    string& operator=(string const& s) {
      free(data);
      strdup(s.data);
      return *this;
    }
    ~string() { free(data); }

    char* data = nullptr;
  };
}

class M {
  std::string s;

public:
  M(std::string t) : s(t) {}
};

int main() {
  M m = m;
}

This started to warn with r11-959 "Implement a solution for PR middle-end/10138
and PR middle-end/95136."

I think this can be considered FIXED for GCC 11.