Re: in_avail() error. Major compliance problem

[David Rasmussen <pinkfloydhomer at yahoo dot com>]

On Sunday 28 October 2001 14:26, Florian Weimer wrote:
> >
> > How do you figure? in_avail shouldn't be blocking according to the
> > standard.
>
> Why do you think so?  There's no way to implement in_avail() in a
> non-blocking manner for line-oriented devices, and it's very hard to
> come up with a formal requirement suitable for standardization which
> describes non-blocking behavior.

I know there is no requirement for non-blocking behavior of the inputstream 
itself. But in_avail() should just check the buffer, that is, a part of 
memory. It has nothing to do with blocking or non-blocking input. It should 
just say "how many characters are in my buffer right now? oh, none. I'll 
return 0."

>
> That's why I doubt that the C++ standard mandates non-blocking
> behavior, and I was unable to find such a reference in the standard.
>

I know, if you're talking about nonblocking input, which I wasn't. It is a 
religious issue. Many people think it is good that this is not mentioned 
others think it is not a good idea. The good people at boost.org, of which 
many is in the C++ standard commitee, certainly thinks that nonblocking input 
should be possible on platforms that supports it. That is, if people try no 
compile it on an embedded device in a microwave oven, it's their own fault. 
It's not as if the rest of the standard is totally non-dependant on certain 
implementation details of hardware. 

> > And it shouldn't return 1 always according to the standard.
>
> Does it do that?  What happens if you press C-d instead of RET?

Same thing.

It worked on gcc 2.95.x . So was that implementation faulty in your opinion? 
I don't think so.