$Config{shortsize} and $Config{longsize} are useless. Those are the sizes of those types your machine/compiler uses. You need the values from the remote machine, which you'll need to hardcode.

Similarly, I disagree with BrowserUK's use of s. You need to use the remote machine's byte order, so you need to use n or v. (Then you'll have to convert it from unsigned to signed, but that's easy: $ping = unpack('s', pack('S', $ping));.)

I just wanted a wrapper class to be able to read from a buffer like this:

But that is exactly what I mean by "fighting unpack". The buffer has a fixed length--2 + 4 + 32 + 1 + 32 + 1 = 72--so deal with it that way.

Your 'wrapper class' is unnecessary and overkill. Stop trying to write Java in Perl and just use Perl.

That's just my opinion. You are, of course, perfectly within your rights to completely ignore it.

You are, of course, perfectly within your rights to completely ignore it.

No, I don't mean to ignore it, I just gave it a try. But it turned out that it's more difficult and it most likely won't work like that (see below).

The buffer has a fixed length--2 + 4 + 32 + 1 + 32 + 1 = 72--so deal with it that way.

It turned out that this is not the case. The 'name' and 'clan' fields are max 32 chars, not fixed at 32 chars. :( When I read constant lengths from it, it only works if all clients use the maximum length for both 'name' and 'clan'.

Funny that you mention Java, btw. You're right: I had to write lots of Java for university recently and the code I may be influenced by that. ;)

On the other hand, this is not just a short script of 50 lines, it's supposed to become a (command line) multi-game server browser. So there's quite a few different buffers I'll have to handle. That's why I structured the code a bit more than I usually tend to in perl...

It turned out that this is not the case. The 'name' and 'clan' fields are max 32 chars, not fixed at 32 chars.

Then your struct definition is wrong.

If the strings are variable length, then use 'Z*':

print for unpack 'n N Z* C Z* C', 
    "\x01\x01\x04\x03\x02\x01The first string\0\xffThe second string\0
+\xff";;
257
67305985
The first string
255
The second string
255
[download]

That's why I structured the code a bit more than I usually tend to in perl...

I'm not suggesting you stop structuring your code, just structure is differently. Java streams are just one possible abstraction of the problem.

I would suggest a different abstraction that uses the power of unpack format strings. Have a different class for each packet and pass the buffer into the constructor and have it remove its stuff from that buffer.

package This::Packet;

sub new {
    my( $class, $bufRef ) = @_;
    my( $ping, $rate, $name, $ctpos, $clantag, $isbot ) 
        = unpack 'n N Z* C Z* C', $$bufRef;
    my $nPacket = 2 + 4 
        + length( $name )+ 1 + 1      ## string + null + ctpos
        + length( $clantag ) + 1 + 1; ## string + null + IsBot

    # ... validate

    substr( $$bufRef, 0, $nPacket, '' ); ## remove this packet from th
+e buffer
    return bless { 
        ping => $ping,
        rate  => $rate,
        name  => $name,
        cpos => $ctpos,
        clantag => $clantag,
        isBot   => $isBot,
    }, $class;
}

## accessors go here
[download]

This way moves all the packets specific information inside a class that deals with that packet. Each class removes it's data from the buffer and the higher level only has to decide which packet to deal with next.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

Yes, I've long wanted "stream" semantics for pack/unpack. If they implemented a "give me the resulting offset" option, then such could be well implemented in a module.