- 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 20:40 "Re: [Tiff] Wrong Native Bit Order on Intel x86_64", by Edward Lam
In the tiff-4.0 source code, I traced the problem to line 16124 of the configure script (or line 327 of configure.ac), where the script
>> checks for i*86* instead of i*86*|x86_64. Unless there is a good
reason for the native bit order to be MSB-to-LSB on x86_64, I believe that this is a bug and needs to be corrected so that all Intel and AMD x86 varieties are properly identified as LSB-to-MSB architectures.
This issue is now fixed in libtiff CVS.
Hopefully someone will speak up if this was the wrong decision.
I doubt it's the wrong decision since we're just being consistent on x86_64 with 32-bit x86 on this matter. If we're wrong here, then that means the original decision on 32-bit x86 was wrong as well. :)
Having said that, it would be nice if we had a regression test of some sort that would actually test this decision. ie. that libtiff will correctly read .tiff files generated with both fill orders.
Regards,
-Edward