Re: Test and endianness

It seems to me from a little browsing around the web that the LSO files are "network" files (little endien) and the endieness of the system storing the files is irrelevant (to the content of the file). The LSO parser should use little endien pack/unpack in its processing regardless of the orientation of the system the code is running on.

That being the case, the tests should run against little endien LSO files (because that is the only sort that there is) and should report failures if the module is failing to convert from little endien to native endien for internal processing.

Perl is environmentally friendly - it saves trees

Comment on Re: Test and endianness

Replies are listed 'Best First'.
Re^2: Test and endianness by andreas1234567 (Vicar) on Jan 16, 2008 at 11:09 UTC
The LSO parser should use little endien pack/unpack This would work fine with `unpack("n")`, but that applies to integers only. Is this possibly also for floating point numbers without resorting to the Perl 5.9.2 `<` and `>` modifiers to unpack? I would prefer to be able to support Perl 5.8. -- Andreas	[reply] [d/l] [select]
Re^3: Test and endianness by almut (Canon) on Jan 16, 2008 at 14:45 UTC
As to the floats (I figure those are the values tagged as "number"): I just tried it on a big-endian machine (Solaris/sparc, flashplayer 9.0.47.0), in addition to little-endian Linux/x86. The results: Flashplayer apparently stores its cookies in the same format, independently of the architecture the player is running on¹ (which confirms what GrandFather wrote). I.e., a hexdump of the buffer (`unpack "H*", $buffer`) in your `_readFloat` routine consistently shows the same pattern, e.g. `4049000000000000` for 50.0 (as found in the `settings.sol` file, which is being created by default the first time the player is started). It seems you can properly decode those values using `unpack 'd', $buffer; # big-endian (e.g. sparc, PA-RISC) # i.e. 'perl -V' showing "byteorder=432 +1" unpack 'd', reverse $buffer; # little-endian (e.g. x86) # i.e. 'perl -V' showing "byteorder=123 +4"` [download] However, I so far haven't been able to test this with "more complex" floats, i.e. not just simple ints (like 50) represented as floats — mainly because I couldn't find a site which would set such a value... but I suppose it would work. (Do you have a link to a site which will make my flashplayer store numbers such as 726.127318273?) ___ ¹ Adobe++ for this, BTW — as it does allow you to share your home directory (~/.macromedia/) across multiple architectures. (Early versions of Firefox got this wrong, for example, storing architecture-dependent stuff in your profile, which made the browser segfault when you switched from one platform to another... (now fixed) )	[reply] [d/l] [select]
Re^4: Test and endianness by andreas1234567 (Vicar) on Jan 16, 2008 at 19:05 UTC
As to the floats (I figure those are the values tagged as "number") Yes. I tried to be consistent with other SOL tools, most of which call any kind of number just that, "number". Flashplayer apparently stores its cookies in the same format, independently of the architecture the player is running on (which confirms what GrandFather wrote). Thank you very much for this information. This probably means one can perform a reverse in the unpack depending on the value of `$Config{byteorder}`. Do you have a link to a site which will make my flashplayer store numbers such as 726.127318273? Currently not. But you can easily create your own, e.g. with the Sol editor (Win32 app, runs fine under Wine). -- Andreas	[reply] [d/l]