From: ara.t.howard@...
Date: 2006-03-31T06:58:26+09:00
Subject: Re: unpack signed short in network (big-endian) byte order

On Fri, 31 Mar 2006, baumanj@gmail.com wrote:

> Perhaps this should be a new subject like "adding formats for
> pack/unpack". I gave this a bit of thought, and there are quite a few
> formats that seem to be missing. I would naturally assume that there
> should be support for each combination of
>
> {unsigned, signed} x {native, network, little-endian} x {short, int,
> long}
>
> However, of these 18 formats, 8 are missing. There are more than enough
> unused characters to specify them (j J k K o O r R t T W y Y z). I
> tried to come up with consistent mappings based on what already exists
> and this is what I came up with (?s indicate that the format is not
> currently supported):
>
> S	unsigned native short
> s	signed native short
> n	unsigned network short
> o ?	signed network short
> v	unsigned little-endian short
> r ?	signed little-endian short
>
> I	unsigned native int
> i	signed native int
> J ?	unsigned network int
> j ?	signed network int
> K ?	unsigned little-endian int
> k ?	signed little-endian int
>
> L	unsigned native long
> l	signed native long
> N	unsigned network long
> y ?	signed network long
> V	unsigned little-endian long
> y ?	signed little-endian long
>
> I'm thinking of submitting an RCR for this, but before I go through the
> effort of figuring out the c code to achieve it, I wanted some opinions
> as to whether this is worthwhile and whether the mappings are sensible.
>
> Thanks.

i use pack/unpack alot and would love to see more types handled.  i'm with
eric on checking perl/python.  however, the reality is that pack/unpack are so
dang cryptic it hardly matters - i always need to read the docs ;-)  that said
they are extremely useful.

good luck.

-a
-- 
share your knowledge.  it's a way to achieve immortality.
- h.h. the 14th dali lama