27.7.1.3 par 8 says:

Notes: The function can make a write position available only if
    ( mode & ios_base::out) != 0. To make a write position
    available, the function reallocates (or initially allocates) an
    array object with a sufficient number of elements to hold the
    current array object (if any), plus one additional write position.
    If ( mode & ios_base::in) != 0, the function alters the read end
    pointer egptr() to point just past the new write position (as
    does the write end pointer epptr()).


The sentences "plus one additional write position." and especially
    "(as does the write end pointer epptr())" COULD by interpreted
    (and is interpreted by at least my library vendor) as:

    post-condition: epptr() == pptr()+1

    This WOULD force sputc() to call the virtual overflow() each time.

The proposed change also affects Defect Report 169.

Proposed change:


Notes: The function can make a write position available only if
    ( mode & ios_base::out) != 0. To make a write position
    available, the function reallocates (or initially allocates) an
    array object with a sufficient number of elements to hold the
    current array object (if any), plus AT LEAST one additional write
    position. THE FUNCTION ALTERS THE WRITE END
    POINTER EPPTR() TO POINT ONE POSITION PAST
    THE END OF THE NEW AVAILABLE WRITE AREA.
    If ( mode & ios_base::in) != 0, the function alters the read end
    pointer egptr() to point just past the new write position.



-- ChristianWBrock <brock AT ivi DOT fhg DOT de>





[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"ChristianWBrock" <0815@ivi.fhg.de> wrote in message
news:<3f713e91$1@news.fhg.de>...
> 27.7.1.3 par 8 says:

> Notes: The function can make a write position available only if
>     ( mode & ios_base::out) != 0. To make a write position
>     available, the function reallocates (or initially allocates) an
>     array object with a sufficient number of elements to hold the
>     current array object (if any), plus one additional write position.
>     If ( mode & ios_base::in) != 0, the function alters the read end
>     pointer egptr() to point just past the new write position (as
>     does the write end pointer epptr()).

> The sentences "plus one additional write position." and especially
> "(as does the write end pointer epptr())" COULD by interpreted (and is
> interpreted by at least my library vendor) as:

It's worse than that.  What you cite is only a (non-normative) note.
The real question is: what is the underlying sequence, which is what
str() will return?  In    27.5.1, it says:

    Each sequence [input or output] is characterized by three pointers
    which, if non-null, all point into the same charT array object.  The
    array object represents, at any moment a (sub)sequence of characters
    from the sequence. [...]

This seems to say that the sequence is at least [pbase()..epptr()[.  And
that stringbuf::str() should return std::string( pbase(), epptr() )
(since according to    27.7.1.2, basic_stringbuf::str() returns a
basic_string object whose content is equal to the basic_stringbuf
underlying character sequence).  So if the stringbuf allocates more
bytes than are actually written, you get undefined behavior, since your
string would consist of uninitialized bytes.

There's obviously something wrong somewhere.

>     post-condition: epptr() == pptr()+1

>     This WOULD force sputc() to call the virtual overflow() each time.

That's what Samuel Krempp concluded too, when the issue came up in
fr.comp.lang.c++.  Given the current wording, he's probably right, and
all of the existing implementations are non-conforming.

Note that the definition of sequence above also causes problems with
filebuf -- the underlying sequence is the file itself, so if the buffer
size is 512, after a sync, the file must also be at least 512 bytes.
Even if you've only written 2 bytes, and the file was empty beforehand.

--
James Kanze           GABI Software        mailto:kanze@gabi-soft.fr
Conseils en informatique orient   e objet/     http://www.gabi-soft.fr
                    Beratung in objektorientierter Datenverarbeitung
11 rue de Rambouillet, 78460 Chevreuse, France, +33 (0)1 30 23 45 16

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]