in reply to Re^2: Write 2 uint16_t numbers to file in Perl
in thread Write 2 uint16_t numbers to file in Perl
Possibly an allusion to the closing sentence in the documentation of the printf function?
Don't fall into the trap of using a printf when a simple print would do. The print is more efficient and less error prone.
| Athanasius <°(((>< contra mundum | Iustus alius egestas vitae, eros Piratica, |
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^4: Write 2 uint16_t numbers to file in Perl
by BrianP (Acolyte) on Jan 05, 2016 at 17:28 UTC | |
Root cause of problem found:
Perl misprints a ushort with %hu format as %c%c
Does Perl have a PrintC function which prints C datatypes
EXACTLY as C would print the same BINARY DIGITS without
dismembering multi-byte integers and misprinting as
single-byte character data? %hu means %hu, !%c%c!
This behavior contradicts sprintf documentation:
Size: h interpret integer as C type "short"
It contradicts C behavior; same data, same printf, wrong result
It fails the intelligent assistant test:
What is the value of $Xres? "+^\" is !correct
Working with uint16 image data without a printf which
understands the difference between characters and ushorts
is a problem. Does one keep 2, parallel sets of data,
1 real set for Photoshop and a second, "doctored" set
to print correctly in the log files?
-------------------------------------------- Test case: 1) pack number into 'S', unsigned short, store in $pxres 2) write $pxres to disk in binary mode 3) dump this file in C to verify contents 4) Include misprint of uint16 as 2 uint8s in C output 5) print $pxres variable in Perl with explicit %d, %hu, %s... Results: Perl does pack and dump uint16 containing number 7360 correctly. Contents verified via C program Perl prints the known good uint16 as 2 uint8 chars Perl printf of 7360 with explicit "%hu" format is identical to C printf of uint16 buffer with %c%c I asked a "2 foot section of rope". Assistant delivered 2, "1 foot sections of rope".--------------------------------------------------------
--------------------------------------------------------
-------------------------------------------------------- ------------------------------------------------ =============================================================== =============================================================== Athanasius, I tried the print instead of printf (and changed my variable name from rgb->hdr)
This is NOT a print/f problem:
It read, unpacked and printed raw, binary UINT16 data correctly
All I have been trying to do is: 1) document current value of uint16_t at some_uint16_array16 Try to imagine square brackets around the "<16>" above. 2) Convert ordinary integer <<7360>> to uint16_t 3) Overwrite old, documented value (the 3689) with new 7360 value 4) Confirm in log file that new value prints EXACTLY like old value 5) Write binary blob back to disk with only 2 uint16s changedHow does one PACK the "S"hort value "'7360'" into an array item created with:
A) It was asked to create an Unsigned SHORTfrom reasonable data: $hdr[\16\]=pack("S", 7360); B) It was asked to print it as an Unsigned SHORT as "%hu" C) It was asked to print the Unsigned SHORT as it saw fit D) How can it print this as: The EXTRACTION part of the Pathological Extraction Report Lang is working! The DATA CREATION seems to have fallen less on the PRACTICAL side :) | [reply] [d/l] [select] |
by AnomalousMonk (Archbishop) on Jan 05, 2016 at 18:02 UTC | |
How does one PACK the "S"hort value "'7360'" into an array item created with: ... Don't. Please see my reply below (update: and also see this more-complete explanation). Assign 7360 to the array element in question and then re-pack the whole array as an S-formatted string. Give a man a fish: <%-{-{-{-< | [reply] [d/l] |