On Tue, Apr 21, 2009 at 09:08:56PM -0400, Jonathan Yu wrote: > On Tue, Apr 21, 2009 at 8:17 PM, Peter Pentchev <r...@ringlet.net> wrote: > > On Tue, Apr 21, 2009 at 10:24:10AM +0100, Paul LeoNerd Evans wrote: > >> I find lately I've been doing a lot of binary protocol work, taking > >> messages that live in TCP streams or files or similar, and doing lots of > >> pack()/unpack() on them. > > [snip] > >> > >> Is there some neater way to do this? Can I either: > >> > >> a: Get unpack() to consume bytes from the LVALUE > >> > >> b: Ask unpack() how much it ate in a generic fashion? > > > > Brief answer: > > - it's possible by patching the Perl source, see the last paragraph > > for an explanation about a possible patch; > > - it could be done as an external module that must be kept in sync > > with Perl's pp_pack.c. > > > > From a quick look at pp_pack.c in both Perl 5.8.9 and Perl 5.10.0, > > both options are possible in theory, but both of them require > > modifying the Perl source in some way :( > > > > The least intrusive way IMHO would be to un-staticize the unpack_rec() > > routine, so either another part of core Perl or a module that > > "promises" to stay in sync with pp_pack's unpackstr() routine actually > > *can* make use of unpack_rec's last argument. > > > > Of course, it is still possible for an external module to duplicate > > the whole of pp_pack.c and take great pains to stay in sync with core, > > but I'm not sure anyone would actually *want* to do that :> Although, > > actually, I hereby volunteer to do it - to try to make a separate Perl > > module out of a copy of 5.10.0's pp_pack.c, and then follow Perl's > > development and update it as needed - that is, if there's anyone who > > actually thinks this would be a good idea and if there's no-one who > > thinks it would be a very bad idea. I can see why it could be a bad > > idea, but here's a call for opinions / votes / whatever :) If people > > want it, I can try. > > > > An easier (from a programmer's point of view) and nightmarish > > (from a module writer's point of view) solution would be a patch to > > Perl that adds another function (say, lunpack()) to pp_pack.c, that > > does pretty much the same as the current unpack(), but also return > > (or store somewhere) the number of bytes consumed. It would only > > be useful if it is actually accepted into the core Perl and makes it > > into a release that you can "require". I think I could write a patch > > like that tomorrow after I've actually had some sleep :) > > If a Perl patch can be made available for this purpose, then why not > an XS/C module?
Yes, I had originally written "(an XS one)" in my "external module"
paragraph above, but I decided to remove it since it seemed kind of
obvious that it would have to be a C module to tweak the internals
that much :)
See my reply to Ben Morrow for some more discussion on unpack(".").
I still think that a module could be useful for older versions of
Perl, and it could be implemented as a no-op for newer ones.
G'luck,
Peter
--
Peter Pentchev r...@ringlet.net r...@space.bg r...@freebsd.org
PGP key: http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553
If the meanings of 'true' and 'false' were switched, then this sentence
wouldn't be false.
pgpkcGf4U1l0b.pgp
Description: PGP signature
