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

Hi everyone,
while composing a reply to To 'pack' or 'unpack' that is the question, I once again stumbled across the following (perceived?) oddity in Perl-5.10's pack docs:

(...)
One or more of the modifiers below may optionally follow some letters in the TEMPLATE (the second column lists the letters for which the modifier is valid):

! sSlLiI Forces native (short, long, int) sizes instead of fixed (16-/32-bit) sizes. xX Make x and X act as alignment commands. nNvV Treat integers as signed instead of unsigned. @. Specify position as byte offset in the internal representation of the packed string. Efficient but dangerous. > sSiIlLqQ Force big-endian byte-order on the type. jJfFdDpP (The "big end" touches the construct.) < sSiIlLqQ Force little-endian byte-order on the type. jJfFdDpP (The "little end" touches the construct.)

In particular, I'd be interested in "Treat integers as signed instead of unsigned".

Is it only my slowly deteriorating sight, or is there really some character missing in front of the "nNvV"? In case of the latter, does anyone know what that modifier should be?

Replies are listed 'Best First'.
Re: Perl 5.10 pack() template modifier "treat signed"
by gwadej (Chaplain) on Nov 11, 2008 at 18:30 UTC

    I'm not completely sure, of course. But it looks like the '!' was meant to apply to four sets of letters, not just 'sSlLiI'.

    G. Wade

      Ah, you're right (...could have sworn I had tried that already!! This time it works ;) — Thanks a lot!

Re: Perl 5.10 pack() template modifier "treat signed"
by ikegami (Patriarch) on Nov 11, 2008 at 20:36 UTC

    Is it only my slowly deteriorating sight, or is there really some character missing in front of the "nNvV"?

    It's still describing "!".

    >perl -le"print unpack 'N', qq{\x81\x23\x45\x67}" 2166572391 >perl -le"print unpack 'N!', qq{\x81\x23\x45\x67}" -2128394905
Re: Perl 5.10 pack() template modifier "treat signed"
by gone2015 (Deacon) on Nov 11, 2008 at 17:51 UTC

    Update: useless parts of posting struck out. Brain fade... sorry :-(

    Well, Nn already work big-endian, and Vv work little-endian.

    There doesn't seem much point these accepting < or > to override (or reenforce) their meaning -- and a quick experiment shows that they are rejected.

    Of course, NnVv work unsigned. There doesn't appear to be a "make signed" qualifier, but you can get signed big-endian and signed little-endian by qualifying sSiIlLqQ to taste.

      Well, Nn already work big-endian, and Vv work little-endian.

      I'm not interested in changing their endianness, but in making them behave in a signed fashion...

      There doesn't appear to be a "make signed" qualifier

      If so, then why have an entry in the table of modifiers for a modifier which doesn't exist? — That's confusing, at best.

        Apologies. I will write out 100 times, "Engage brain for longer before touching keyboard".

        In mitigation: I was convinced that because 'l<' and 'l>' gave signed 'V' and 'N', respectively, that there was no need for anything else -- and no need for the table to show any qualifier for 'nNvV'. Also I couldn't see much point in forcing 'nNvV' native... but then, in those cases '!' is the very signed qualifier I didn't think existed :-(

        All in all, not a good posting. Sorry.