[Bug libstdc++/48355] New: Assigning NULL to string segfaults

[amr.ali.cc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48355

   Summary: Assigning NULL to string segfaults
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amr.ali...@gmail.com
  Host: Linux 2.6.35-28-generic #49-Ubuntu SMP x86_64


Created attachment 23813
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23813
Bug reproducible code

When trying to call the ctor of string() or basic_string, allocator >() with a NULL pointer parameter (instead
of the char pointer), it would abort() with a logic_error saying that NULLs
aren't allowed.

Which is the result of the following code:

basic_string.tcc
 133 // NB: Not required, but considered best practice.
 134 if (__gnu_cxx::__is_null_pointer(__beg) && __beg != __end)
 135   __throw_logic_error(__N("basic_string::_S_construct null not
valid"));

However, when trying to assign NULL to a string, it doesn't do
__is_null_pointer() check and tries to call __builtin_strlen on the pointer,
which of course, results in the infamous SIGSEGV.

I'd say either make the behavior for the assign() equal to the ctor or
preferably instead just have an empty string when assigned a NULL pointer.

I'd happily write a patch for this myself, I just need a few pointers of where
this should be fixed. I've looked around in basic_string.{h,tcc} and
char_traits.h but still a little confused.

NOTE:
Attached a code snippet to reproduce the behavior mentioned above.

Checked Against:
OSX v10.6.7 - GCC v4.2.1
Linux v2.6.35-28-generic - GCC v4.4.5/v4.5.1

[Bug libstdc++/48355] Assigning NULL to string segfaults

[amr.ali.cc at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48355

--- Comment #3 from Amr Ali  2011-03-30 09:13:57 
UTC ---
(In reply to comment #2)
> duplicate of PR 5258 and PR 994
> 
> I'll look into checking when _GLIBCXX_DEBUG is defined but the default
> (non-debug mode) behaviour is NOT going to change, your code has a bug, your
> code should change not the standard library

Yes, I'm not saying that what I'm doing is "right", I'm rather pointed out that
the code actually segfaults, which shouldn't happen even with a faulty value
like a NULL pointer.

I'm only suggesting that a check for a null pointer be present as in the
string() ctor case.