[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS update [cvs1-11-x-branch]: /ccvs/src/
From: |
Derek Robert Price |
Subject: |
Re: CVS update [cvs1-11-x-branch]: /ccvs/src/ |
Date: |
Wed, 25 Aug 2004 16:21:27 -0400 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mark D. Baushke wrote:
> Derek Robert Price <derek@ximbiot.com> writes:
>
> >Hey Mark,
>
> >This is better than before and it would probably take a larger file
> >than you built in sanity.sh to prove it, but I believe this can still
> >lose data. Just because select returned ready for the file descriptor
> >doesn't mean that the descriptor is necessarily ready for LEN bytes of
> >data. fwrite() is defined to return the number of bytes written.
> >Assuming that works when the file is in non-blocking mode, then this
> >code will probably need to loop over remaining bytes until everything
> >is written.
>
>
> I was under the impression that fwrite() returned the number of objects
> written that were of size bytes... We are only asking to write one
> object in our calls to fwrite.
>
> So, as our current calls are asking to write one object of size bytes
> and there is no way to know how many bytes were actually written when
> the fwrite operation completes.
I think I would have to classify that as a typo based on the use of
sizeof (*args) to determine the number of objects.
Rereading the C89 specification of fwrite(), however, it appears that
this wouldn't be the right way to go anyhow:
The fwrite() function returns the number of elements successfully
written, which will be less than NMEMB only if a write error occurred.
and earlier:
If an error occurs, the resulting value of the file position
indicator for the stream is indeterminate.
Which would seem to imply that if fwrite() returns a low byte count
then we cannot depend on the stream pointer even to be after the last
byte written.
> >CC'ing bug-cvs in case anyone can correct me or expound.
>
>
> As Larry has already mentioned, mixing file descriptor operations (like
> select) with stdio is not a 'safe' thing to do.
Well, no, but I'm fairly certain that an fflush() of the stdio stream
followed by exclusive use of file descriptor operations is safe.
> In an ideal world, we would probably move away from using the stdio
> library entirely and use raw file operations such as the write() and
> select() and pay close attention to the return values.
Sounds like this would be the only sound way to go. One more item for
the TODO list.
Cheers,
Derek
- --
*8^)
Email: derek@ximbiot.com
Get CVS support at <http://ximbiot.com>!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFBLPTGLD1OTBfyMaQRAh/KAJ9OGlx3xZZR6cTsKXgLwY0Gl5W8nQCg+gb/
m8VLT1OWoiC5htc6GPM8RvI=
=vc2U
-----END PGP SIGNATURE-----