On Tue, 2013-08-13 at 08:44 -0500, Joel Sherrill wrote: > Could you post a small self contained example please?
See attached (apologies if it's been stripped...). "make RTEMS_MAKEFILE_PATH=..." (with GNU make) should do the trick. Commenting the lseek() or setting the offset to 0 should produce correct results, with a 0 returned from the subsequent read(). It seems I have to rtems_tarfs_load() the file to reproduce; I was unable to do so with an open()-created file. -- Nick Withers Embedded Systems Programmer Room 2.26, Building 57 Department of Nuclear Physics Research School of Physics and Engineering The Australian National University (CRICOS: 00120C) eMail: nick.with...@anu.edu.au Phone: +61 2 6125 2091 Mobile: +61 414 397 446 > Nick Withers <nick.with...@anu.edu.au> wrote: > > > Hey all, > > (I'm not on the -devel list; please include me in any possible replies, > if you'd like me to see them) > > I seem to be able to reliably trigger an exception when using lseek() to > jump past the EOF of a file on IMFS, followed by a read(). > > I believe this should not occur, per > http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html : "No > data transfer shall occur past the current end-of-file. If the starting > position is at or after the end-of-file, 0 shall be returned. If the > file refers to a device special file, the result of subsequent read() > requests is implementation-defined" > > This is on an MVME3100 (PowerPC) with Git HEAD RTEMS, circa 2013-08-12. > > I've got a stack trace (not totally sure I trust it) if someone'd like? > Perhaps lseek() isn't supported on IMFS? The file in question's been > rtems_tarfs_load()ed there, if that could make a difference...? > > If it's meant to work, would you like me to file a bug report with the > stack trace?
lseek_read.tar.gz
Description: application/compressed-tar
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
