If you just want "the values", then keep them as strings. If that seems problematic, you have to show some code where you show how you acquire the data (say, from initializing a string), how you unpack it, and what you want to do with it in the end.

If you want "the values" as "number", then you have to unpack them from the string. As long as you are dealing with four-byte numbers, or your Perl and the C program have the same interpretation of the long type, there will be no loss of accuracy.

As for your questions about alignment etc., that is what Convert::Binary:C is set up to handle.

Turns out my debug routine was the thing splitting from string representations of the decimal values. Unpack and Convert::Binary::C were working fine. Dunce cap. :-) Binary makes me woozy.

The C struct has unsigned longs mostly. Each of these is 32 bytes, right?

I would not bet on that. The C99 standard defines int as having the natural size suggested by the architecture of the execution environment (large enough to contain any value in the range INT_MIN to INT_MAX as defined in the header <limits.h>)., so an int needs at least 16 bits. Other integer types, including unsigned long, are definied similary. C requires a minimum range, but no fixed number of bits. The implementation may choose bit sizes as required by the machine. So most C compilers on 32 bit systems actually define int as a 32 bit number, long int is typically 32 or 64 bit. But if you run on a 36 bit architecture without a 32 bit emulation layer, int should use 36 bit, long int may use 72 bit, and long long int could use 144 bit. Things get more complicated on 64 bit systems that attempt to support 32 bit software, see http://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models. Note that UNICOS defines all basic integer types as 64 bit.

See also http://stackoverflow.com/questions/589575/size-of-int-long-etc, http://en.wikipedia.org/wiki/C_data_types.

Alexander