develooper Front page | perl.perl5.porters | Postings from January 2012

Re: pack and ASCII

Thread Previous | Thread Next
Eric Brine
January 13, 2012 11:14
Re: pack and ASCII
Message ID:
On Fri, Jan 13, 2012 at 8:30 AM, John P. Linderman (jpl) <> 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

C<< pack "A20", $text >> is useful for formatting text for display, such as
C<ls>'s default multi-column display,

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About