stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <j...@apache.org>
Subject [jira] Commented: (STDCXX-1026) sgetn() fails to extract characters from an unbuffered stream
Date Wed, 10 Dec 2008 22:20:48 GMT

    [ https://issues.apache.org/jira/browse/STDCXX-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655387#action_12655387
] 

Martin Sebor commented on STDCXX-1026:
--------------------------------------

After pondering this some more and re-reading the spec several times I'm not sure the test
case is valid. I sent the question below to the C++ reflector to get a clarification. Regardless
of the outcome, though, the committed fix to {{xsgetn()}} should still be fine even if the
spec doesn't specify the behavior when the overridden {{underflow()}} doesn't behave exactly
as required. It just makes the function more robust.

{quote}
-------- Original Message --------
Subject: difference between null and empty pending sequence
Date: Wed, 10 Dec 2008 14:23:56 -0700
From: Martin Sebor <sebor AT roguewave DOT com>
Reply-To: c++std-lib AT accu DOT org
Organization: Rogue Wave Software, Inc.
To: undisclosed-recipients:;

To: C++ libraries mailing list
Message c++std-lib-22975

I've been staring at the text for {{streambuf::underflow()}} for
so long that I've gotten myself confused enough and need help
interpreting it.

My question is this: is {{underflow()}} allowed to return non-EOF
without setting {{gptr() < egptr()}}?

I suspect what's confusing me are these two sentences (emphasis
mine):

    ??Returns??: ... If the pending sequence is *null* then
    the function returns {{traits::eof()}} to indicate failure.

and:

    The ??result character?? is:

    b) If the pending sequence is *empty* then the next
       character that would be read from the input sequence.

What is the difference between a *null* pending sequence and
one that's *empty*, and is the ??result character?? supposed
to the same as the result of the function (i.e., the return
value)?

Note that the definition of "result character" is italicized
in the text and that the only other reference to it is in
{{uflow()}} later in the same section.

Thanks
Martin
{quote}

> sgetn() fails to extract characters from an unbuffered stream
> -------------------------------------------------------------
>
>                 Key: STDCXX-1026
>                 URL: https://issues.apache.org/jira/browse/STDCXX-1026
>             Project: C++ Standard Library
>          Issue Type: Bug
>          Components: 27. Input/Output
>    Affects Versions: 4.2.1
>            Reporter: Martin Sebor
>            Assignee: Martin Sebor
>             Fix For: 4.2.2
>
>   Original Estimate: 2h
>          Time Spent: 2h
>  Remaining Estimate: 0h
>
> This bug was uncovered in this [discussion | http://forums.sun.com/thread.jspa?messageID=10532349]:
> {noformat}
> $ cat t.cpp && make t && ./t
> #include <cassert>
> #include <istream>
> #include <streambuf>
> int main ()
> {
>     static int x = '0';
>     struct: std::streambuf {
>         // unbuffered, always successfully reads one character
>         int_type underflow () { return x++; }
>     } sb;
>     // "endless" stream that never reaches EOF
>     std::istream endless (&sb);
>     char s [4] = "";
>     endless.read (s, sizeof s);
>  
>     // expect to extract as many characters as requested
>     assert (endless.good ());
>     assert (sizeof s == endless.gcount ());
>     assert ('0' == s [0] && '1' == s [1] && '2' == s [2] && '3'
== s [3]);
>     
> }
> gcc -c -I/home/sebor/stdcxx-4.2.1/include/ansi \
>        -I/home/sebor/stdcxx-4.2.1/include \
>        -I/build/sebor/stdcxx-4.2.1-gcc-4.3.0-8D/include \
>        -I/home/sebor/stdcxx-4.2.1/examples/include \
>        -pedantic -nostdinc++ -O2   -W -Wall \
>        -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   t.cpp
> t.cpp: In function 'int main()':
> t.cpp:9: warning: inlining failed in call to 'virtual main()::<anonymous struct>::~._26()':
call is unlikely and code size would grow
> t.cpp:24: warning: called from here
> t.cpp:9: warning: inlining failed in call to 'virtual main()::<anonymous struct>::~._26()':
call is unlikely and code size would grow
> t.cpp:24: warning: called from here
> gcc t.o -o t  -L/build/sebor/stdcxx-4.2.1-gcc-4.3.0-8D/lib  -Wl,-R/build/sebor/stdcxx-4.2.1-gcc-4.3.0-8D/lib
-lstd8D -lsupc++ -lm 
> t: t.cpp:22: int main(): Assertion `endless.good ()' failed.
> Aborted
> {noformat}

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message