This is the mail archive of the
mailing list for the libstdc++ project.
Completely unexplicable (to me ;) behaviour of read (vs fread)
- From: Paolo Carlini <pcarlini at unitus dot it>
- To: "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>
- Cc: Nathan Myers <ncm at cantrip dot org>
- Date: Sat, 08 Mar 2003 21:17:04 +0100
- Subject: Completely unexplicable (to me ;) behaviour of read (vs fread)
regtesting the fix for 7744, which I'm preparing along the
lines already discussed in detail, I'm seeing completely
unexpected failures in filebuf_virtuals.cc.
Consider this sequence:
c1 = fb_03.sgetc();
c2 = fb_03.sungetc();
Sungetc() calls pbackfail() which, then, calls underflow here:
// At the beginning of the buffer, need to make a
// putback position available.
// But the seek may fail (f.i., at the beginning of
// a file, see libstdc++/9439) and in that case
// we return traits_type::eof()
if (this->seekoff(-1, ios_base::cur) >= 0)
Inside underflow the new _M_file.xsgetn() is called, which, when
the last parameter is false means read instead of fread:
__elen = _M_file.xsgetn(reinterpret_cast<char*>(_M_in_beg),
The new xsgetn is:
__basic_file<char>::xsgetn(char* __s, streamsize __n, bool __stdio)
return fread(__s, 1, __n, _M_cfile);
errno = 0;
__ret = read(this->fd(), __s, __n);
while (__ret == -1L && errno == EINTR);
The big mistery is that read (vs fread) in this situation returns _zero_
instead of one! No chars are read.
Any idea what I'm doing wrong?
Thanks once more,
P.S. I have already tried clearing O_NONBLOCK (as will eventually be the
case, after the fix for 9533), with no differences.