- 2009.10.06 23:19 "Re: [Tiff] SourceForge terms changes, heads up", by Graeme Gill
-
2009.10.07 20:11 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Eskandar Ensafi
- 2009.10.07 19:25 "[Tiff] Wrong Native Bit Order on Intel x86_64", by Eskandar Ensafi
- 2009.10.07 20:24 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Toby Thain
- 2009.10.07 21:26 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn
- 2009.10.08 15:09 "Re: [Tiff] SourceForge terms changes, heads up", by Ron
2009.10.07 21:43 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Bob Friesenhahn
On Wed, 7 Oct 2009, Toby Thain wrote:
>
> As I understand it, the problem is not in the reading and writing code or > runtime behaviour, but relates to determination of the built default (May not
> match platform's "actual" machine default.)
>
> The 'bug' would be at build-time, but it seems relatively unimportant to get > right, esp. for a C library.
I hope that you don't mind that I am Cc:ing this response to the list since it is an important issue to correct properly.
If the default is wrong, then the best-case penalty is that CPU is wasted executing TIFFReverseBits() when writing and reading files on the same system and the user explicitly specified the fill-order tag correctly for the CPU. The worst-case penalty is that the files can't be read by some other host. Since it took three years for this issue to be reported, the worst-case penalty seems unlikely since interoperability issues are noticed right away, and because no one has reported fill-order issues on unusual CPUs.
Bob
--
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/