Re^3: C types and SV's

I'm aware of that, so my translation was mostly what the C code said. The C code is not portable for exactly the reason you cite, because the word size may vary (with the advent of 64-bit architectures) again. If I were to really implement a tiff reader, I would look at the documentation again, or at existing implementations, to make sure that reading the data reads the number of bytes and treats them correctly. I'm sure that for TIFF, there is a definition of endianness, and then one could switch to the Nn or Vv unpack templates instead of using the architecture dependent Ii templates.

Comment on Re^3: C types and SV's Select or Download Code

Replies are listed 'Best First'.
Re^4: C types and SV's by DrHyde (Prior) on Jul 19, 2010 at 10:47 UTC
TIFF can be big- or little-endian. There's a marker in the file to tell you which one it is.	[reply]
Re^5: C types and SV's by blakew (Monk) on Jul 19, 2010 at 20:14 UTC
DrHyde, since I'm not writing my own TIFF reader but calling the libtiff API, for example if I read data in from this function, which states: The library attempts to hide bit- and byte-ordering differences between the image and the native machine by converting data to the native machine order. Bit reversal is done if the FillOrder tag is opposite to the native machine bit order. 16- and 32-bit samples are automatically byte-swapped if the file was written with a byte order opposite to the native machine byte order do I have to worry about your concerns, or will Perl's pack/unpack be sufficiently general? Thanks.	[reply]
Re^6: C types and SV's by DrHyde (Prior) on Jul 20, 2010 at 10:03 UTC
Sounds like you should be OK, but to be on the safe side, I'd write some specific tests for this, and verify that files with both byte orders work on machines with both byte orders, and with both 32- and 64-bit native ints. You can outsource the testing to the CPAN-testers, of course.	[reply]