public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
       [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
@ 2024-06-13 16:09 ` redi at gcc dot gnu.org
  2024-06-13 16:13 ` redi at gcc dot gnu.org
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2024-06-13 16:09 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
MSVC sets badbit, just like we do:

https://github.com/microsoft/STL/blob/e36ee6c2b9bc6f5b1f70776c18cf5d3a93a69798/stl/inc/__msvc_string_view.hpp#L483
(and other lines in that function).

Libc++ sets both failbit and badbit:

https://github.com/llvm/llvm-project/blob/dc8e078a59a65a8e2b4dd13954bfa497b30ef0e8/libcxx/include/__ostream/basic_ostream.h#L514

The requirement to set failbit came from
https://cplusplus.github.io/LWG/issue211 and certainly seems consistent with
other input operations, which set failbit not badbit.

N.B. https://wg21.link/p1264r2 cleaned up the wording for input operations,
making it clear that badbit should only be set by the library after an input
operation throws an exception.

The libc++ behaviour seems like a reasonable compromise between what the
standard says and what existing user code might be expecting (based on the
behaviour of both MSVC and libstdc++).

I'm unsuspending this to reopen it. I think we should *at least* set failbit.
I'm ambivalent whether we continue to set badbit as well.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
       [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
  2024-06-13 16:09 ` [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure redi at gcc dot gnu.org
@ 2024-06-13 16:13 ` redi at gcc dot gnu.org
  2024-06-13 16:13 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2024-06-13 16:13 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #3)
> The requirement to set failbit came from
> https://cplusplus.github.io/LWG/issue211 and certainly seems consistent with
> other input operations, which set failbit not badbit.
> 
> N.B. https://wg21.link/p1264r2 cleaned up the wording for input operations,
> making it clear that badbit should only be set by the library after an input
> operation throws an exception.

Oops that's for input ops and this is about output!

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
       [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
  2024-06-13 16:09 ` [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure redi at gcc dot gnu.org
  2024-06-13 16:13 ` redi at gcc dot gnu.org
@ 2024-06-13 16:13 ` redi at gcc dot gnu.org
  2024-06-13 16:45 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2024-06-13 16:13 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For output, the requirement to set failbit was present since C++98, not added
by a DR.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
       [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2024-06-13 16:13 ` redi at gcc dot gnu.org
@ 2024-06-13 16:45 ` redi at gcc dot gnu.org
  2024-06-13 17:17 ` redi at gcc dot gnu.org
  2024-06-14 11:15 ` redi at gcc dot gnu.org
  5 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2024-06-13 16:45 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It looks like we've been setting badbit in ostream::_M_write(const charT*,
streamsize) since it was added in r0-47606-g8d0a564bba54f7

That function was used to replace the similar code in basic_ostream::write:

          streamsize __put = this->rdbuf()->sputn(__s, __n);
          if ( __put != __n)
            this->setstate(ios_base::badbit);

and in the operator<< for std::basic_string:

          streamsize __res = __out.rdbuf()->sputn(__s, __len);
          __out.width(0);
          if (__res != __len)
            __out.setstate(ios_base::failbit);

However that created the problem, because basic_ostream::write is indeed
specified to set badbit but the string inserter sets failbit.

[ostream.unformatted] says:
"inserting in the output sequence fails (in which case the function calls
setstate(badbit)"

[string.io] defers to [string.view.io] which defers to [ostream.formatted]
which says:
"If the generation fails, then the formatted output function does
setstate(ios_base::failbit)"

So we have different requirements for ostream::write and string insertion, but
we implement them both the same way since r0-47606-g8d0a564bba54f7 (the
_M_write member was later replaced  by __ostream_write but that uses the same
logic and sets badbit).

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
       [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
                   ` (3 preceding siblings ...)
  2024-06-13 16:45 ` redi at gcc dot gnu.org
@ 2024-06-13 17:17 ` redi at gcc dot gnu.org
  2024-06-14 11:15 ` redi at gcc dot gnu.org
  5 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2024-06-13 17:17 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think we can just do this in __ostream_insert:

--- a/libstdc++-v3/include/bits/ostream_insert.h
+++ b/libstdc++-v3/include/bits/ostream_insert.h
@@ -103,6 +103,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
              else
                __ostream_write(__out, __s, __n);
              __out.width(0);
+
+             if (__builtin_expect(__out.bad(), 0))
+               __out.setstate(__ios_base::failbit);
            }
          __catch(__cxxabiv1::__forced_unwind&)
            {

If __ostream_write or __ostream_fill fails to insert something (as unformatted
output functions) they'll set badbit. So we can check for that and set failbit
explicitly, to meet the requirement for a formatted output function.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
       [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
                   ` (4 preceding siblings ...)
  2024-06-13 17:17 ` redi at gcc dot gnu.org
@ 2024-06-14 11:15 ` redi at gcc dot gnu.org
  5 siblings, 0 replies; 8+ messages in thread
From: redi at gcc dot gnu.org @ 2024-06-14 11:15 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Paolo Carlini from comment #2)
> Basing on posts to the LWG reflector + private converstation, it seems
> likely that the standard is moving to the behavior which is currently
> implemented by libstdc++, relatively to badbit vs failbit. Therefore, for
> now I'm suspending the PR, will add a DR number in due course. In any case,
> we don't lack tricky iostreams corner cases to work on... ;)

It looks like Martin did file this, as LWG 394, which was closed as NAD.
https://cplusplus.github.io/LWG/issue394

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
  2006-06-20 18:21 [Bug libstdc++/28103] New: " sebor at roguewave dot com
  2006-06-20 19:09 ` [Bug libstdc++/28103] " pcarlini at suse dot de
@ 2006-06-22 16:28 ` pcarlini at suse dot de
  1 sibling, 0 replies; 8+ messages in thread
From: pcarlini at suse dot de @ 2006-06-22 16:28 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from pcarlini at suse dot de  2006-06-22 16:10 -------
Basing on posts to the LWG reflector + private converstation, it seems likely
that the standard is moving to the behavior which is currently implemented by
libstdc++, relatively to badbit vs failbit. Therefore, for now I'm suspending
the PR, will add a DR number in due course. In any case, we don't lack tricky
iostreams corner cases to work on... ;)


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

* [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure
  2006-06-20 18:21 [Bug libstdc++/28103] New: " sebor at roguewave dot com
@ 2006-06-20 19:09 ` pcarlini at suse dot de
  2006-06-22 16:28 ` pcarlini at suse dot de
  1 sibling, 0 replies; 8+ messages in thread
From: pcarlini at suse dot de @ 2006-06-20 19:09 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from pcarlini at suse dot de  2006-06-20 19:09 -------
Thanks Martin.


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pcarlini at suse dot de
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-20 19:09:03
               date|                            |


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


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2024-06-14 11:16 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-28103-4@http.gcc.gnu.org/bugzilla/>
2024-06-13 16:09 ` [Bug libstdc++/28103] std::operator<<(ostream&, string) sets badbit instead of failbit on failure redi at gcc dot gnu.org
2024-06-13 16:13 ` redi at gcc dot gnu.org
2024-06-13 16:13 ` redi at gcc dot gnu.org
2024-06-13 16:45 ` redi at gcc dot gnu.org
2024-06-13 17:17 ` redi at gcc dot gnu.org
2024-06-14 11:15 ` redi at gcc dot gnu.org
2006-06-20 18:21 [Bug libstdc++/28103] New: " sebor at roguewave dot com
2006-06-20 19:09 ` [Bug libstdc++/28103] " pcarlini at suse dot de
2006-06-22 16:28 ` pcarlini at suse dot de

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).