Front page | perl.perl5.porters |
Postings from January 2012
Re: pack and ASCII
Thread Previous
|
Thread Next
From:
Eric Brine
Date:
January 12, 2012 08:40
Subject:
Re: pack and ASCII
Message ID:
CALJW-qEsmH0jW_VzYcGM5hfki4PQkJX0Ncb+bSfRAS9Mw1xwzA@mail.gmail.com
On Thu, Jan 12, 2012 at 8:58 AM, John P. Linderman (jpl) <
jpl@research.att.com> wrote:
> I am *not* proposing that the behavior of "A" be changed. Too much code
> would break. However, the list of "surprises" that might happen when ASCII
> text is replaced with general unicode text should be mentioned.
>
Yes, I realise you are only asking for a documentation changes (or a new
letter for new behaviour). Others are advocating changes to the existing
behaviour, though. My comments are directed at them. I'm sorry you got
caught in the middle.
**
> 2) I have many applications that write records of fixed length (measured
> in octets). Files of such records can easily be searched with binary
> search, and it is trivial to read the Nth record. If this is a fringe
> requirement, there's not a lot left to say. But I suspect I am not alone
> in finding this a convenient format.
>
I fully agree you should be able to do this.
> 6) The C<<$reclen = length(pack($format))>> metaphor is just a lower limit
> on record lengths.
>
Only if you both forgot to encode your text and peek at Perl internals.
(C<print> does the latter, but will warn when it does so.)
7) C<<print $fh $pack-output>> may grouse about wide characters (I regard
> this as a feature, but it can nevertheless be a surprise).
>
Excellent, so Perl did report the error to you. Add encode() before pack(),
and you're good to go.
- Eric
Thread Previous
|
Thread Next