libstdc++/6750: ofstream incorrectly sets failbit (severe regression)

[Peter Schmid]

|    This no longer cores, but it does set bad bit. You seem to think
|    that setting badbit is not good. Well then, what? Throw an
|    exception (which was suggested on the reflector list, but I think
|    compatibility with streambuf* NULL is a better fit.) Do you agree
|    that this is unspecified behavior?

Dear Benjamin,

according to my understanding of the standard, cf. clause 27.6.2.5.4,
template<class charT, class traits>
basic_ostream<charT,traits>& operator<<(basic_ostream<charT,traits>& out,
const charT*   s), etc

are only defined if s is non-null. Therefore, writing a null pointer,
in contrast to writing a zero length string (this is the scenario
described in this PR), is undefined.

I kindly ask you to revert your patch for the following reasons. First of
all, your patch breaks legal code, e.g. confer this PR and PR
libstdc++/6745 , since it does not distinguish between a NULL pointer
and a zero length string, which is wrong according to the standard.

Secondly, regardless what your are doing to avoid the core dump,
either by setting a bit or raising an exception, on
writing a null pointer, you will introduce a libstdc++ specific
extention, making user code of one of the most used facilities of the
c++ library non portable.

When I first encountered this "feature" of the iostream facility, I
assumed that the standards committee did not specify what should happen
when c is null on purpose since IMHO there is no general way of
processing a null pointer in the library. Only the writer of the
application code knows how to process and handle this border line case.

Futhermore, recently many extensions of the library were moved to
extension headers or removed completely. Therefore, I do not
understand why there is a need for your patch, implementing another
extension.

Libstdc++-v2 prints [Null] for a null pointer, but this is not a general
solution.

Finally, you are introducing an additional if clause, thus io
will be slower (maybe this is marginal, though).

Best regards,

Peter Schmid