LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
February 2010
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2010.02.26 17:05 "Re: Patch for tif_unix.c", by Bob Friesenhahn
On Fri, 26 Feb 2010, Eric Doenges wrote: > I have a small patch for tif_unix.c that I would like to see included in > libtiff 4.0 if possible. The problem is that tif_unix.c assumes that > read() and write() will be able to read and write the number of > requested bytes in one go. While this assumption seems to hold (for disk > files) on all Unix systems I have ever worked on, it is not guaranteed > by POSIX, and we do have one system (TI TMS320C6X using TI's compiler > and C runtime) where file I/O can only be done in small chunks (256 > bytes in this case). There is some code which looks very much like this in GraphicsMagick but with the primary intention to deal with system calls which are interrupted by a signal. While the approach used in GraphicsMagick would deal with the short read/write issue, I had never considered that a system would have an issue with the size of the data passed. The similar code in GraphicsMagick is in the FilePositionRead() and FilePositionWrite() functions viewable on the web at "http://cvs.graphicsmagick.org/cgi-bin/cvsweb.cgi/GraphicsMagick/magick/pixel_cache.c?rev=1.67;content-type=text%2Fx-cvsweb-markup". It does not seem like your patch deals with the case where the system call returns -1 to indicate an error. This is important to deal with properly since otherwise the software could lock up. Can you fix this and re-submit your patch? While it is useful to post to this list, always remember to open a bug report on libtiff Bugzilla and post your patch there as well. Bob -- Bob Friesenhahn bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer, http://www.GraphicsMagick.org/