Bug 37957 - Wrong behaviour of num_get<>::do_get(bool) in the case when one target sequence is a prefix of the other one
Summary: Wrong behaviour of num_get<>::do_get(bool) in the case when one target sequen...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: unknown
: P3 normal
Target Milestone: 4.4.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-30 14:21 UTC by Andrey Tsyvarev
Modified: 2008-11-11 12:08 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
reproduce bug (419 bytes, text/plain)
2008-10-30 14:22 UTC, Andrey Tsyvarev
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrey Tsyvarev 2008-10-30 14:21:14 UTC
There are some examples in the description of member function of the num_get<> facet

iter_type do_get(iter_type in, iter_type end, ios_base& str, ios_base::iostate& err, bool& val) const

for the case when (str.flags() & ios_base::boolalpha) != 0, that clarify the algorithm that the function implements (22.2.2.1.2, p16):

For targets true: "a" and false: "abb", the input sequence "a" yields val == true and err == str.eofbit; the input sequence "abc" yields err = str.failbit, with in ending at the 'c'. 

In the last example, however, the attached test program shows the following:

andrew@Ubuntu:/mnt/hgfs/shared/temp/test$ g++ test.cpp && ./a.out
failbit wasn't set, and result is true
Rest of stream is 'bc'.

It seems (from this and other tests), that the implementation stops reading from 'in' when it founds a sequence that matches one of the target sequences.
But it should test, whether the sequence is a (proper) prefix of another target sequence. And if it is, the function should continue reading.

This behaviour doesn't follow obviously from the description of the function, but it follows from the examples.

The detailed bug description can be found at: 

http://linuxtesting.org/results/report?num=S0736
Comment 1 Andrey Tsyvarev 2008-10-30 14:22:51 UTC
Created attachment 16589 [details]
reproduce bug
Comment 2 Andrey Tsyvarev 2008-11-11 10:22:50 UTC
This bug was fixed with fixing of bug 37958.
Testcase for bug 37958 also covers this one.
Comment 3 Paolo Carlini 2008-11-11 12:08:40 UTC
.