bug-cvs
[Top][All Lists]
Advanced

[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 <address@hidden> 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: address@hidden

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-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]