in reply to Re: String eval is cool
in thread String eval is cool

IMO the eval version is much clearer than anything involving pack/unpack could be.
$ perldoc -f eval|wc -c 6610 $ perldoc -f pack|wc -c 23377
That's right, pack's documentation is over three and a half times longer, and is littered with platform dependencies, arbitrary one character magic values, and special cases. It's so complicated that it needs a 51,000 character tutorial to go with it.

And your use of << is buggy. On a 32 bit machine the results are undefined. On a 64-bit machine you lose the obvious relationship between the /bits and the netmask (you'll have too many 1 bits) although the results will still be correct as the extra 1s will be ANDed with 0 and so thrown away later.

Replies are listed 'Best First'.
Re^3: String eval is cool
by ikegami (Patriarch) on Jun 27, 2006 at 14:16 UTC

    IMO the eval version is much clearer than anything involving pack/unpack could be.

    True, but that's why it was isolated into a small function with a clear purpose. Modularisation introduces ease of testing, which allows for hiding of complicated code. Have you looked at the guts of the modules you use? You'll find similar complexity.

    Speaking of, this should be done with a module such as NetAddr::IP.

    On a 32 bit machine the results are undefined.

    Oops. I'm used to doing these operations in assembler where portability is a non-issue, so I changed my solution while posting. My original solution (follows) doesn't suffer from that problem, and also works on 64-bit perls unmodified:

    $mask = 0xFFFFFFFF >> (32-$bits) << (32-$bits);