If a Perl patch can be made available for this purpose, then why not an XS/C module?
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 :) > > 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 > I am the meaning of this sentence. >
