Front page | perl.perl5.porters |
Postings from January 2012
Re: pack and ASCII
Thread Previous
|
Thread Next
From:
Eric Brine
Date:
January 11, 2012 15:00
Subject:
Re: pack and ASCII
Message ID:
CALJW-qHc9M7E2wGjTvmbQw8Akbg_ZM1MWpH9XzpSRBS1q+m15Q@mail.gmail.com
On Wed, Jan 11, 2012 at 3:44 PM, Jesse Luehrs <doy@tozt.net> wrote:
> On Wed, Jan 11, 2012 at 02:38:48PM -0500, Eric Brine wrote:
> > Of course, the bug would only manifest itself if you feed C<pack> bad
> data
> > in the first place. Perhaps you should fix *that* bug instead of trying
> to
> > change the function of C<< pack "A" >>. C<< pack "A" >> is documented to
> > work on text, and that's what it does. Obviously, it's never been limited
> > to 7-bit ASCII text inputs, but it's not limited to 8-bit text inputs
> > either.
>
> Actually, pack 'A' is documented to work on ASCII - I thought that's how
> this entire thread came up.
>
"Actually" makes it sound like you're contradicting me, but you just
repeated what I said. I'll rephrase in case I wasn't clear.
- It has always* been documented to work on ASCII text.
- It has never* been limited to ASCII characters.
- It has never* been documented to work on bytes.
* -- To my knowledge.
Also, nobody is arguing that the issue is anything other than bad data
> being fed to pack.
Then what do you think I've been saying?
C<< pack "A20A20", chr(0x2660), chr(0x2660); >> is perfectly acceptable, so
you can't warn or change it's behaviour without breaking it!
chr(0x2660) is only bad data because jpl's has extra limitations on what
his strings can contain. That has nothing to do with pack.
> The issue is whether pack should do something to tell
> the user that they are feeding bad data to pack.
>
The issue is whether pack should _*be changed*_ to tell
the user that they are feeding bad data to _*JPL's program*_.
- Eric
Thread Previous
|
Thread Next