AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2017.08.02 15:00 "[Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
2017.08.02 15:26 "Re: [Tiff] Error handling in Read/Write/Seek", by Bob Friesenhahn
2017.08.03 15:04 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
2017.08.03 15:23 "Re: [Tiff] Error handling in Read/Write/Seek", by Bob Friesenhahn
2017.08.04 15:27 "Re: [Tiff] Error handling in Read/Write/Seek", by Even Rouault
2017.08.07 15:53 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
2017.09.06 07:48 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
2017.09.06 10:32 "Re: [Tiff] Error handling in Read/Write/Seek", by Even Rouault
2017.09.06 13:16 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF
2017.09.07 14:06 "Re: [Tiff] Error handling in Read/Write/Seek", by Even Rouault
2017.09.08 07:50 "Re: [Tiff] Error handling in Read/Write/Seek", by Nicolas RUFF

2017.08.02 15:26 "Re: [Tiff] Error handling in Read/Write/Seek", by Bob Friesenhahn

The real fix would be some kind of out-of-band error reporting (a la errno). Such a change would be transparent to all users of ReadOK / WriteOK / SeekOK macros, but I wonder if there are people in the wild checking return values on their own.

This is a private header so there should be no other users of these macros besides libtiff.

It seems best to block any negative size values from being passed into these functions in the first place. Libtiff is not in control of the I/O functions, so it is best to assure that they are not passed illegal values which might cause I/O implementations to do very bad things.

Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/