[ECOS] read() - problem with returned value?

["Jurica Baricevic" <jura at INTESIS dot hr>]

Hi!

I noticed a problem regarding read() function (file 'io.cxx'). It seems to
me that read() is not completely in compliance with POSIX standard. Since I
am not so acquainted with the standard to make the final statement, I am
just guessing that there is a flaw. And after searching the eCos mailing
list archive - it seems that I am not the only one who noticed this:

http://sources.redhat.com/ml/ecos-discuss/2001-05/msg00216.html
http://sources.redhat.com/ml/ecos-discuss/2001-06/msg00623.html
http://sources.redhat.com/ml/ecos-discuss/2001-06/msg00639.html

Anyway, it looks that the problem was never worked out, so I will point it
out again.

Namely, return value of read() is defined (as far as I know):
+ On success: the number of bytes read is returned (zero indicates end of
file).
+ On error (including EWOULDBLOCK): the -1 is returned, and errno is set
appropriately.

Apparently the current eCos read() implementation [more precisely:
readwrite()] in non-blocking mode returns '0' in case of EWOULDBLOCK
(instead of '-1'). This might break some existing code, which relies on '0'
as a signal for end of file. In addition, the same code possibly might
expect '-1' before checking if 'errno' is set to EWOULDBLOCK. In both cases,
the code won't run appropriately on eCos.

I have observed this 'flaw' with a network application (read() from tcpip)
that has been executing correctly on RTEMS and Windows for long period of
time. Moreover, the code has been executing fine on eCos without FILEIO
package where read() is implemented in 'net/tcpip/current/src/lib/read.c'.
Unluckily, after I added the FILEIO package to my configuration, the code
was broken due to the different behavior of FILEIO read(). Specifically, '0'
is returned when '-1' is expected (on errno=EWOULDBLOCK).

Therefore, I believe that the current implementation of FILEIO 'read()' has
a flaw (comparing with both the NET package read() and the standard).

Any comment is appreciated.

Thanks,
Jura