This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
When you're using VMIN=0, VTIME=255 you have ICANON=0 so 'end-of-file' doesn't really exist.
I switched to calling read() and as documented, it always returns 0 when there is no data. When the connection is dropped, it returns 0 VERY quickly. Do you think this part is a bug in the read on a socket?
If this turns into an RTEMS specific issue, we need to switch lists. But I would really like to know what is correct. :)
On Dec 17, 2009, at 2:16 PM, Joel Sherrill wrote:
Hi,
I have been looking into a program on RTEMS that uses VMIN=0, VTIME=255. The program calls fgetc() which calls read().
fp->_flags == 0x2806 before the fgetc() call. read() times out and returns 0. fgetc() returns -1 and fp->_flags == 0x2826
The 0x0020 being set is _SEOF.
My questions are:
+ Is this correct behaviour?
+ How does the application programmer distinguish between a real EOF and an unsatisfied read? Even the Fedora read(2) man page says:
On success, the number of bytes read is returned (zero indicates end of file), and the file position is advanced by this number.
So even if I dropped down to read(2), I still don't know how to distinguish EOF from a read timeout.
Thanks.
-- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
-- Joel Sherrill, Ph.D. Director of Research& Development joel.sherrill@OARcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |