On Tue Aug 09 01:46:04 2011, STEFFENW wrote:
Show quoted text> The way out of that problem is to calculate the string length of a
> formatted number like this....
The problem comes when you've asked it to format the output as quads (64 bit values) but
only have enough data for, for example, 5 of the last 8 bytes. While I agree that padding with
zeroes is problematic, anything else means that the last the last line of output will not be
formatted as quads. It would be highly misleading to, for example, format it as a 32 bit value
and an 8 bit value, especially when you take endian-ness into account.
However, what you've been bitten by is the incompatible change in the most recent version,
noted here:
http://search.cpan.org/~dcantrell/Data-Hexdumper-
3.00/lib/Data/Hexdumper.pm#INCOMPATIBLE_CHANGES which is a result of my switching to
a more flexible way of specifying output formats. Unfortunately an implementation detail
(number_formats are implemented in terms of the new output_format) means that old-style
number_formats now have to be padded to multiples of sixteen bytes. The code will have
emitted warnings about that, unless you have suppress_warnings turned on.
I would be happy to accept a patch to fix this - at least to fix the problem with padding if
using number_format - but it ain't gonna be simple.
