Front page | perl.perl5.porters |
Postings from August 2012
Re: RFC: pack()ing long words
Thread Previous
|
Thread Next
From:
Craig A. Berry
Date:
August 13, 2012 17:18
Subject:
Re: RFC: pack()ing long words
Message ID:
CA+vYcVzU5q=M+OpzEmRHu0oMf=rmSKoq+NKOUB-C=i3eZckn0Q@mail.gmail.com
On Mon, Aug 13, 2012 at 5:35 PM, David Cantrell <david@cantrell.org.uk> wrote:
> On 13/08/2012 20:32, demerphq wrote:
>> On 13 August 2012 20:31, Leon Timmermans <fawaka@gmail.com> wrote:
>>> On Mon, Aug 13, 2012 at 8:16 PM, David Cantrell <david@cantrell.org.uk> wrote:
>>>> I haven't looked at the source (and am somewhat
>>>> terrified to do so TBH) but I can see that getting a bit tricky.
>>>
>>> pp_pack.c is where you need to be. It's rather full of "tricky".
>>
>> And that is the diplomatic way to put it. :-)
>
> I shouldn't have looked, but I did. It is dark and full of terrors, and
> I want my mummy.
>
> Thankfully, all I'm asking for right now is that the syntax be defined,
> so that I can go ahead and implement it in my module, and make sure I
> use the same magic letter as pack() will do if pack/unpack ever sprout
> this tentacle in the future. So if people agree that this is a good
> thing to do, all that actually needs patching for now is the
> documentation, something like ...
>
> x A null byte (a.k.a ASCII NUL, "\000", chr(0))
> X Back up a byte.
> +
> + Y NOT YET IMPLEMENTED. This syntax is reserved for a word of
> + an arbitrary number of bits. The number of bits is
> + specified as a base ten number in {braces}, eg Y{40} for
> + a forty bit (or five byte) word.
> +
> @ Null-fill or truncate to absolute position, counted from the
> start of the innermost ()-group.
> . Null-fill or truncate to absolute position specified by
> the value.
pp_pack.c has its terrors, but even I can see that if you unpack an
integer type you get an IV or a UV on the stack (that's what mPUSHi
and mPUSHu do). What is it you want pushed on the stack when you
unpack a 16-byte word? It's not going to be anything that Perl can
represent as a numeric value unless you also implement
arbitrary-precision numerics. Or have I misunderstood what you're
wanting?
Thread Previous
|
Thread Next