peschkaj has asked for the wisdom of the Perl Monks concerning the following question:

I'm looking at the docs for recv() on perldoc.com, and I am unsure as to what I am seeing/reading. The docs indicate that the SCALAR will shrink or grow as necessary, regardless of LENGTH specified.

However, I have noticed that by specifying a nessage length, the message gets truncated (is that the right word?) to LENGTH. Example:

my $msgLength = 12; # send_client is the length of the incoming message. my $send_client = recv( $client, $message, $msgLength, 0 );

Am I missing something in this code? I'm assuming this truncation is correct, but what does recv() actually do with these parameters? Is there a way to dynamically increase the size of LENGTH? Or is it always fixed to a certain byte size?

Thanks

If you make something idiot-proof, eventually someone will make a better idiot.
I am that better idiot.

Replies are listed 'Best First'.
Re: recv byte length problem?
by robartes (Priest) on Nov 06, 2002 at 14:10 UTC
    What the docs actually say is:
    SCALAR will be grown or shrunk to the length actually read.
    I take this to mean that SCALAR will have the number of bytes read, but not regardless of LENGTH. If the number of bytes read is less than LENGTH (e.g. the socket has closed), then the length of SCALAR will be less then LENGTH as well. If however, there are more bytes in the socket's buffer than LENGTH, SCALAR will contain LENGTH bytes, and the remaining bytes stay in the socket buffer.

    So, the actually read part is specified for the case where you read less bytes than LENGTH.

    As to dynamically increasing LENGTH, I do not know what you mean exactly, but you can specify a different length in different recv()'s:

    recv($socket, $string1, 512, 0); recv($socket, $string2, 256, 0):

    CU
    Robartes- hoping this makes some sense

      Ah, that makes sense. I mis-read it to mean that SCALAR will be the same size as the message received. Although, your explanation makes much more sense than my interperetation.

      When I wrote about dynamically increasing length I wasn't terribly clear. Sorry.

      What I really should have asked is: Should I set my LENGTH quite high to provide for future capabilities, or should I, instead, make sure that I size LENGTH appropriately now and determine an effective protocol to use that is verbose enough to deal with anything I can throw at it?

      In retrospect it's a silly question and I should go with the latter of the two solutions: settle on a specific size of message to accept and write code accordingly.

      Thanks, ++Robartes.

      If you make something idiot-proof, eventually someone will make a better idiot.
      I am that better idiot.