This is the mail archive of the
mailing list for the GCC project.
Re: in_avail() error. Major compliance problem
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
> 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?
It worked on gcc 2.95.x . So was that implementation faulty in your opinion?
I don't think so.