This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos 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]

Re: read() - problem with returned value?


On Fri, 2001-12-28 at 08:54, Jurica Baricevic wrote:
> 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.

It looks like there is a missing "check for error" in the readwrite 
path.  Can you try this patch and see if it fixes it?  Let us know and
if it fixes your problem, we'll commit it.

Index: io/fileio/current/src/io.cxx
===================================================================
RCS file: /home/cvs/ecc/ecc/io/fileio/current/src/io.cxx,v
retrieving revision 1.5
diff -u -5 -p -r1.5 io.cxx
--- io/fileio/current/src/io.cxx	1 Nov 2000 16:30:53 -0000	1.5
+++ io/fileio/current/src/io.cxx	28 Dec 2001 16:15:17 -0000
@@ -117,10 +117,13 @@ static ssize_t readwrite( int fd, void *
     LOCK_FILE( fp );
     
     ret = op( fp, &uio );
     
     UNLOCK_FILE( fp );
+
+    if( ret != 0 )
+        FILEIO_RETURN(ret);
     
     cnt -= uio.uio_resid;
 
     cyg_fp_free( fp );
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]