[ 
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.

Reply via email to