Front page | perl.perl5.porters |
Postings from January 2012
Re: pack and ASCII
From: Jesse Luehrs
January 13, 2012 13:05
Re: pack and ASCII
Message ID: 20120113210527.GU23629@tozt.net
On Fri, Jan 13, 2012 at 02:14:35PM -0500, Eric Brine wrote:
> On Fri, Jan 13, 2012 at 8:30 AM, John P. Linderman (jpl) <
> firstname.lastname@example.org> 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,
Why would you not just use sprintf("%-20s", $text) here? Making pack
more difficult to use in order to reproduce already existing behavior
doesn't seem to be incredibly helpful.