Core dump constructing a C++ string with NULL

Core dump constructing a C++ string with NULL

[Tom Browder]

It would be nice if this would construct an empty string:

  #include <string>
  std::string s(0);

At the moment that gives a core dump.

Is that defined behavior according to the standard?  If not, what
about a g++ enhancement?

Thanks.

Regards.

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA

Re: Core dump constructing a C++ string with NULL

[Brian Budge]

I think that std::string can only be constructed with a valid non-zero
(including terminator) length char *.

You could do this:

char const *val = whatever;
std::string s( val ? val : "");

  Brian

On Thu, Jan 13, 2011 at 11:56 AM, Tom Browder <tom.browder@gmail.com> wrote:
> It would be nice if this would construct an empty string:
>
>  #include <string>
>  std::string s(0);
>
> At the moment that gives a core dump.
>
> Is that defined behavior according to the standard?  If not, what
> about a g++ enhancement?
>
> Thanks.
>
> Regards.
>
> -Tom
>
> Thomas M. Browder, Jr.
> Niceville, Florida
> USA
>

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 13 January 2011 19:56, Tom Browder wrote:
> It would be nice if this would construct an empty string:
>
>  #include <string>
>  std::string s(0);
>
> At the moment that gives a core dump.

Not if you catch the exception.

> Is that defined behavior according to the standard?

basic_string(const charT* s, const Allocator& a = Allocator());
9        Requires: s shall not be a null pointer.

> If not, what about a g++ enhancement?

We throw an exception, as a gnu extension:

terminate called after throwing an instance of 'std::logic_error'
  what():  basic_string::_S_construct NULL not valid
Aborted (core dumped)




> Thanks.
>
> Regards.
>
> -Tom
>
> Thomas M. Browder, Jr.
> Niceville, Florida
> USA
>

Re: Core dump constructing a C++ string with NULL

[Ian Lance Taylor]

Tom Browder <tom.browder@gmail.com> writes:

> It would be nice if this would construct an empty string:
>
>   #include <string>
>   std::string s(0);
>
> At the moment that gives a core dump.
>
> Is that defined behavior according to the standard?  If not, what
> about a g++ enhancement?

The standard says that you may only pass a valid pointer to the
std::string constructor.  You are passing an invalid pointer, so your
code is undefined.

As to whether libstdc++ should check for NULL, that is a perennial
question: should we slow down the library a tiny bit for everybody in
order to do better handling of an undefined case for those who find it
more convenient?  There is no clearly correct answer.

Ian

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Thu, Jan 13, 2011 at 14:59, Ian Lance Taylor <iant@google.com> wrote:
> Tom Browder <tom.browder@gmail.com> writes:
>
>> It would be nice if this would construct an empty string:
>>
>>   #include <string>
>>   std::string s(0);
>>
> As to whether libstdc++ should check for NULL, that is a perennial
> question: should we slow down the library a tiny bit for everybody in
> order to do better handling of an undefined case for those who find it
> more convenient?  There is no clearly correct answer.

How about a compiler option then, something like
"--allow-c++-null-string-constructor"...

Regards,

-Tom

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 14 January 2011 16:19, Tom Browder wrote:
>
> How about a compiler option then, something like
> "--allow-c++-null-string-constructor"...

We throw an exception, std::logic_error, indicating a precondition violation.

Silently ignoring a problem and acting as though a different
constructor was called encourages non-portable code.
It's also an additional maintenance burden, for questionable benefit.
I certainly don't want to have to test my changes to std::string twice
with different builds.

If you don't care about portability you're free to modify the code
yourself for your own use.

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Fri, Jan 14, 2011 at 10:47, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 14 January 2011 16:19, Tom Browder wrote:
>>
>> How about a compiler option then, something like
>> "--allow-c++-null-string-constructor"...
>
> We throw an exception, std::logic_error, indicating a precondition violation.

Two questions:

1.  does it take any significant time difference to check for a 0
versus throw an exception (one argument against)?

2.  Isn't a '\0' an empty string in the string context?

Respectfully,

-Tom

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 14 January 2011 16:59, Tom Browder wrote:
>
> Two questions:
>
> 1.  does it take any significant time difference to check for a 0
> versus throw an exception (one argument against)?

You have to check for 0 to decide whether to throw an exception or not.
(The alternative is to not check, and segfault, which was the old
behaviour in libstdc++)

I couldn't care less about how slow the function is in the case of a
precondition violation (null string, the exceptional path). We do care
about the performance of the correct case (non-null string.)

> 2.  Isn't a '\0' an empty string in the string context?

std::string("") is an empty string. std::string('\0') is not.

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 14 January 2011 17:05, Jonathan Wakely wrote:
> On 14 January 2011 16:59, Tom Browder wrote:
>>
>> Two questions:
>>
>> 1.  does it take any significant time difference to check for a 0
>> versus throw an exception (one argument against)?
>
> You have to check for 0 to decide whether to throw an exception or not.
> (The alternative is to not check, and segfault, which was the old
> behaviour in libstdc++)
>
> I couldn't care less about how slow the function is in the case of a
> precondition violation (null string, the exceptional path). We do care
> about the performance of the correct case (non-null string.)
>
>> 2.  Isn't a '\0' an empty string in the string context?
>
> std::string("") is an empty string. std::string('\0') is not.

... std::string("\0") is also empty.

But passing '\0' to the string constructor creates a string containing a '\0'

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Fri, Jan 14, 2011 at 11:06, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 14 January 2011 17:05, Jonathan Wakely wrote:
>> On 14 January 2011 16:59, Tom Browder wrote:
...
>>> 2.  Isn't a '\0' an empty string in the string context?

Sorry, I meant "string(0)".

-Tom

Re: Core dump constructing a C++ string with NULL

[Ian Lance Taylor]

Tom Browder <tom.browder@gmail.com> writes:

> 2.  Isn't a '\0' an empty string in the string context?

I thought you were asking about std::string(0), which is quite a
different matter from std::string('\0').

Ian

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Fri, Jan 14, 2011 at 11:38, Ian Lance Taylor <iant@google.com> wrote:
> Tom Browder <tom.browder@gmail.com> writes:
>
>> 2.  Isn't a '\0' an empty string in the string context?
>
> I thought you were asking about std::string(0), which is quite a
> different matter from std::string('\0').

What I'm poorly trying to say is that, even if the string is passed a
null pointer, that appears to be an empty string in the context of a
string, so an option to accept it as such is not unreasonable.

I understand that the null pointer is probably an error up stream, and
this might not be portable.  But the whole point of C++ striings I
thought was to be a safe string immune from pointer problems.

-Tom

Re: Core dump constructing a C++ string with NULL

[Brian Budge]

Nothing is immune to pointer problems that violate preconditions.

I'm curious; is it really easier to modify the compiler than to write
your string construction as I proposed?  Or, even better, if you
control the code that returns the char*, return "" instead of NULL.

  Brian

On Fri, Jan 14, 2011 at 9:43 AM, Tom Browder <tom.browder@gmail.com> wrote:
> On Fri, Jan 14, 2011 at 11:38, Ian Lance Taylor <iant@google.com> wrote:
>> Tom Browder <tom.browder@gmail.com> writes:
>>
>>> 2.  Isn't a '\0' an empty string in the string context?
>>
>> I thought you were asking about std::string(0), which is quite a
>> different matter from std::string('\0').
>
> What I'm poorly trying to say is that, even if the string is passed a
> null pointer, that appears to be an empty string in the context of a
> string, so an option to accept it as such is not unreasonable.
>
> I understand that the null pointer is probably an error up stream, and
> this might not be portable.  But the whole point of C++ striings I
> thought was to be a safe string immune from pointer problems.
>
> -Tom
>

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Fri, Jan 14, 2011 at 11:48, Brian Budge <brian.budge@gmail.com> wrote:
> Nothing is immune to pointer problems that violate preconditions.
>
> I'm curious; is it really easier to modify the compiler than to write
> your string construction as I proposed?

Here's the situation:

open source library A (http://brlcad.org) with many kloc of C code by
many people over decades
  - possible lots of hidden null ptr string bugs remaining (one found
just recently)

open source library A++ wrapping lib A

user of A++ gets stuck and finds one of the null char* bugs as it is
used to construct a C++ string

user of A++ can't fix A++

Now consider my original suggestion with this modification:

  consider it a built-in try {} catch {} block and trap the exception
and return an empty string as well as report the problem to stderr

The compiler option might be something like:

  "--auto-catch-c++-null-string-exception"

Now the user may be able to carry on and he can also report the bug.

Regards,

-Tom

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 15 January 2011 12:33, Tom Browder wrote:
>
> Here's the situation:
>
> open source library A (http://brlcad.org) with many kloc of C code by
> many people over decades
>  - possible lots of hidden null ptr string bugs remaining (one found
> just recently)
>
> open source library A++ wrapping lib A
>
> user of A++ gets stuck and finds one of the null char* bugs as it is
> used to construct a C++ string
>
> user of A++ can't fix A++
>
> Now consider my original suggestion with this modification:
>
>  consider it a built-in try {} catch {} block and trap the exception
> and return an empty string as well as report the problem to stderr
>
> The compiler option might be something like:
>
>  "--auto-catch-c++-null-string-exception"
>
> Now the user may be able to carry on and he can also report the bug.

It can't be a compile-time option, it would create ODR violations if
some files are compiled with that option and others are not.  So it
would have to be an option used when building and installing GCC.

Rather than rebuilding GCC with that option, it would be quicker and
easier to fix the open-source library yourself, or if you really think
it's a good idea to ignore that error, just patch your local GCC
headers in order to be able to carry on.

You're asking for us (the libstdc++ maintainers) to maintain an
additional configuration option which increases the burden of testing
and maintaining the library, for questionable benefit.  Yes, there's a
use case, but is it really significant?  Adding that option would mean
changes to std::string need to be evaluated in terms of impact on the
default configuration, and --enable-fully-dynamic-string, and your
proposed option, and all the combinations of those - that would be
four combinations to consider.

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Sat, Jan 15, 2011 at 07:51, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 15 January 2011 12:33, Tom Browder wrote:
>>
>> Here's the situation:
...
>> The compiler option might be something like:
>>
>>  "--auto-catch-c++-null-string-exception"
>>
...

> It can't be a compile-time option, it would create ODR violations if
> some files are compiled with that option and others are not.  So it
> would have to be an option used when building and installing GCC.
>
> Rather than rebuilding GCC with that option, it would be quicker and
> easier to fix the open-source library yourself, or if you really think
> it's a good idea to ignore that error, just patch your local GCC
> headers in order to be able to carry on.

Okay, good point.  Then how about this:

  a g++ extension for a "dyn_string" ("full dynamic string") that has
that behavior

(It's the Scotch-Irish in me.)

Regards,

-Tom

Thomas M. Browder, Jr.
Niceville, Florida
USA

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 15 January 2011 14:05, Tom Browder wrote:
>
>  a g++ extension for a "dyn_string" ("full dynamic string") that has
> that behavior

How are you going to change a third-party library to use that?!

(I don't know why you picked that name, fully dynamic string is an
existing option, nothing to do with handling null pointers, see the
libstdc++ configure docs for details.)

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 15 January 2011 14:12, Jonathan Wakely wrote:
> On 15 January 2011 14:05, Tom Browder wrote:
>>
>>  a g++ extension for a "dyn_string" ("full dynamic string") that has
>> that behavior
>
> How are you going to change a third-party library to use that?!

Wouldn't it be easier to change the code to not pass a null pointer to
a std::string, than to change it to use a new, incompatible string
class?!

Or just use a helper function to construct your strings:

inline std::string safe_string(const char* s)
{ return s ? s : ""; }

There are many ways to solve this problem portably, but you seem
fixated on making the standard library change to accommodate broken
code.

Re: Core dump constructing a C++ string with NULL

[Tom Browder]

On Sat, Jan 15, 2011 at 08:15, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 15 January 2011 14:12, Jonathan Wakely wrote:
>> On 15 January 2011 14:05, Tom Browder wrote:
...
> Or just use a helper function to construct your strings:
>
> inline std::string safe_string(const char* s)
> { return s ? s : ""; }

You're right--that's probably the best solution for now.

> There are many ways to solve this problem portably, but you seem
> fixated on making the standard library change to accommodate broken
> code.

There's probably a lot more of that in the wild than ours...

Thanks for your patience and consideration Jonathan, Brian, and Ian.

Regards,

-Tom

Re: Core dump constructing a C++ string with NULL

[Jonathan Wakely]

On 14 January 2011 17:43, Tom Browder wrote:
> On Fri, Jan 14, 2011 at 11:38, Ian Lance Taylor <iant@google.com> wrote:
>> Tom Browder <tom.browder@gmail.com> writes:
>>
>>> 2.  Isn't a '\0' an empty string in the string context?
>>
>> I thought you were asking about std::string(0), which is quite a
>> different matter from std::string('\0').
>
> What I'm poorly trying to say is that, even if the string is passed a
> null pointer, that appears to be an empty string in the context of a
> string, so an option to accept it as such is not unreasonable.

I don't know what you mean by the context of a string, but I don't
think it's the case that a null pointer is the same as an empty
string, in any context.  The C and C++ standard libraries certainly
doesn't treat them the same.

If you mean that in the string's constructor, 0 and "" are the same,
that's definitely not true.
One is a null pointer and one is a pointer to an array of one char.

> I understand that the null pointer is probably an error up stream, and
> this might not be portable.  But the whole point of C++ striings I
> thought was to be a safe string immune from pointer problems.

I don't think that's "the whole point" at all - automatic memory
management is at least as important IMHO.  They're certainly not
immune to problems caused by unterminated strings, or null pointers.