incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anton Pevtsov" <>
Subject RE: test for
Date Tue, 27 Jun 2006 15:44:25 GMT
Martin, the changes look goog, but I have a question about __rw_insert:

When macro _RWSTD_NO_EXT_KEEP_WIDTH_ON_FAILURE is defined the width(0)
will be called only if __pad > 0. But pad can be <= 0 when len >= width.

I propose to add '.' after "if (len < width)" to the comment:

    // writes out max(len, width) characters, padding appropriately
    // (with the fill character) if (len < width)
    // calls width(0) if and only if the write has been successful
    // (i.e., will leave it unchanged if sputn fails or throws an
    // exception)

because this comment may be treated as "if (len < width) calls width(0)

Also it may be useful to remove lines:

#else   // if defined (_RWSTD_NO_EXT_KEEP_WIDTH_ON_FAILURE)
                __strm.width (0);   // reset width unconditionally

and append these lines:

            __strm.width (0);   // reset width unconditionally

right after:

                __err = _STD::ios_base::badbit;#ifdef 

What do you think about this?

Anton Pevtsov

-----Original Message-----
From: Martin Sebor [] 
Sent: Tuesday, June 27, 2006 04:13
Subject: Re: test for

Anton Pevtsov wrote:
> The possible fix of the STDCXX-206 and STDCXX-205 is here 
> It required changes in several places:
> What do you think about this?

I'm still thinking about what the best way to deal with it is and
discussing it with others. I made similar changes last week and
implemented the proposed resolution I mentioned previously. I tested
them with an updated version of the width test (the original contained a
number of bugs that I fixed last Friday):

The changes are attached for your review. The new behavior is guarded by
the _RWSTD_NO_EXT_KEEP_WIDTH_ON_FAILURE macro. Defining the macro
disables the new behavior and enables the behavior required by the
current standard (except for the boolalpha part which is just a silly
mistake in the standard).


View raw message