in reply to Re: C types and SV's
in thread C types and SV's and unpack

The problem here is that, in the general case (which the OP may not care about, I'll admit) using plain ol' pack/unpack isn't very portable, as you have to tell it how the structure is laid out in memory. And C makes very few guarantees about that. Merely by looking at the data you can't tell, for example, whether you have a 16-, 32- or 64-bit value; you can't tell whether a word is signed or unsigned; you can't tell whether a structure has been padded with empty space so that its members are on word boundaries; and so on.

I'd take a look at Convert::Binary::C, and in particular the ccconfig script that comes with it.

Replies are listed 'Best First'.
Re^3: C types and SV's
by Corion (Patriarch) on Jul 19, 2010 at 09:53 UTC

    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.

[reply]
[d/l]
[select]
      TIFF can be big- or little-endian. There's a marker in the file to tell you which one it is.
[reply]
        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]

In Section Seekers of Perl Wisdom