Problems? Is your data what you think it is? | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
I'm not sure if this helps ...
Heh ... it helps ... but only in that it reaffirms what I already knew ;-) I'll elaborate a little on how this all came about. As I mentioned in the opening post, with perl-5.34.0, pack's 'D' templates are allowed on all builds irrespective of whether $Config{nvtype} is 'double' or 'long double' or '__float128'. In earlier perl versions the 'D' templates were supported only if $Config{nvtype} was 'long double'. With perl-5.34.0 and nvtype of 'long double' we get: whereas with perl-5.34.0 and nvtype of double, the same command yields a slightly different result: That's pretty much as I expected because the string being unpacked in the first one-liner is different to the string being unpacked in the second one-liner. But then I wanted to see what the result would be if the string created on the long double build (in the first one-liner) was fed to the 'double' build (in the second one-liner). Would the result be 9a999999999999990040000000000000 or 00989999999999990040000000000000 ? (I was quite sure it would be the former, but I knew that if I didn't check then I'd get it wrong.) So I thought I'd do something cute: I decided that, on my 'long double' build, I would run the following script: But, as already demonstrated, that doesn't DWIM. In the end, I took the clunky approach of running 2 scripts. Firstly, on the 'long double' build of perl-5.34.0 I ran the following script that would print the string returned by pack() to a file: Then, on the 'double' build of perl-5.34.0, I ran a script that passed the string that was saved in packstr.txt to unpack(): That script output 9a999999999999990040000000000000. (Hmph ... as if it was ever going to do anything else ...) It just would have been so much cleaner and simpler if I could have got the first approach to work. Cheers, Rob In reply to Re^2: pack() returns an unusable string
by syphilis
|
|