C++ wrapper iostream input bug

[Marc Glisse]

On Mon, 19 Apr 2010, Helmut Jarausch wrote:

> On 19 Apr, Marc Glisse wrote:
>> On Mon, 22 Mar 2010, Helmut Jarausch wrote:
>>
>>> The 'operator>>' in the C++ wrapper library fails if the input
>>> is not terminated by white space - see the example.
>>> This doesn't fail for the input operator in general, just for
>>> gmpxx.
>>
>> Hello,
>>
>> let me check whether I understand how it works.
>
> Unfortunately it's even worse.
>>
>> 1) when the exception mask is clear, gmp works fine (actually there is a
>> bug that makes it clear the eof flag too eagerly, but let's ignore that
>> for now)
>
> On a "standard" Linux system it works since it only occurs at the very
> last input. So, if one doesn't check the flags, it works.
> But I noticed this bug when running an application on MinGW.
> There, this input is just ignored which made the application fail.
> (And was quite hard to locate).

I am not sure I understand what you are saying. Did you have the failbit 
exception mask set (just like the exemple you posted) in the mingw app 
that failed? I am not sure what difference mingw is supposed to make 
compared to linux.

>> 2) it may happen that the fail flag is temporarily set and then cleared
>> during the execution of the function.
>>
>> ==> Things would work as you expect if for such functions gmp saved the
>> exception mask, cleared it, executed the current code and finally restored
>> the mask.
>>
>
> But, turning exceptions off is something like a compatibility option for
> "old" code. Modern code will (should?) turn exceptions on.
> Therefore it's a bug even on a "standard" Linux system.

I did not talk about turning off exceptions, just clearing the exception 
mask of the stream, i.e. the option that tells the stream whether it 
should raise an exception when it sees an eof or fail or bad state (as 
opposed to just keeping that information in the state flag).

> I think it should be easy to correct. If the EOF or EOS condition occurs
> during initial white space skipping or before reading the very first
> digit, it's a true EOF error condition. If it occurs after at least one
> digit has been read it's absolutely normal and the EOF condition should
> only be reported after one tries to read again from that istream.

That is not what happens when I read into a basic type like int. The first 
case you describe is a fail|eof and the second one is eof.

The easiest would probably be that I write a patch matching my 
understanding so you can try it.

-- 
Marc Glisse