This is the mail archive of the
libstdc++@sourceware.cygnus.com
mailing list for the libstdc++ project.
Re: filebuf.in_avail
- To: Anthony Williams <anthony at anthonyw dot cjb dot net>
- Subject: Re: filebuf.in_avail
- From: brent verner <brent at rcfile dot org>
- Date: Wed, 7 Jun 2000 18:22:17 -0400
- Cc: libstdc++ at sourceware dot cygnus dot com
- References: <003a01bfd080$e56d7390$5919cac2@derwent.co.uk>
on Wed, Jun 07, 2000 at 02:04:20PM +0100, Anthony Williams typed aloud:
| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
|
| For an empty file, filebuf.in_avail() returns -1, which is checked
| for in the test suite.
|
| However, I wonder whether this is in fact compliant. Surely it makes
| no sense to be able to retrieve -1 characters without error? Isn't
| zero a far more sensible value?
| It certainly wouldn't be in violation of the standard for an
| implementation to return zero, so this ought to be permitted in the
| testsuite.
27.5.2.2.3
streamsize in_avail();
Returns: If a read position is available, returns egptr() - gptr().
Otherwise returns showmanyc() (27.5.2.4.3).
...
27.5.2.4.3
streamsize showmanyc();
Returns: an estimate of the number of characters available in the
sequence, or -1. If it returns a positive value, then successive
calls to underflow() will not return traits::eof() until at least
that number of characters have been supplied. If showmanyc() returns
-1, then calls to underflow() or uflow() will fail.
underflow() returns traits::eof() to indicate failure.
my reading of this is that in_avail() should return -1 when EOF ...
I can't see where it _could_ return 0;
(first time reading the _real_ standard, so I could be _all_ wrong ;)
Brent
--
Damon Brent Verner
Cracker JackŪ Certified Professional
brent@rcfile.org, brent@linux1.org