Front page | perl.perl5.porters |
Postings from January 2012
Re: pack and ASCII
Thread Previous
|
Thread Next
From:
Eric Brine
Date:
January 13, 2012 11:14
Subject:
Re: pack and ASCII
Message ID:
CALJW-qEr1wfCX4o8J20TB_5j=467S_vs9RZgL1e+RcRUARx79A@mail.gmail.com
On Fri, Jan 13, 2012 at 8:30 AM, John P. Linderman (jpl) <
jpl@research.att.com> wrote:
> **
> Some of the "magic" is gone if it is necessary to explicitly encode before
> packing and decode after unpacking. It's too late to have "A20" do what I
> meant, but we can make it relatively painless if there is a "pack pragma"
> (or something similar) that turns on that behavior without having to
> (otherwise) modify programs. "That behavior", just to be clear, means
> interpreting the number following "A" (or "a") as the number of octets that
> will be stored, with "pack" utf-encoding the data prior to padding, and
> "unpack" utf-decoding the octets after stripping off the padding. (What to
> do if it is necessary to truncate the encoded octets needs thought.
> Truncate at the previous character boundary and pad? Warn?)
>
That could possibly be done using a pattern modifier (e.g. C<< pack("A!20",
$text) >>) instead of a pragma.
It might be useful for pack to modify the argument such that it holds any
text that didn't fit.
> Although it is now irrelevant, I'm having trouble thinking of where the
> current behavior is useful. Why would one want to pad to a specified
> character (not octet) length? -- jpl
>
C<< pack "a20", $bytes >> is useful for creating C structs and fixed-length
records.
C<< pack "A20", $text >> is useful for formatting text for display, such as
C<ls>'s default multi-column display,
Thread Previous
|
Thread Next