Unpack signed short in network (big-endian) byte order

Ruby
1

Is there any particular reason why there is no format specifier in the
String.unpack method for unpacking a signed short in network byte
order? There seems only to be one for unsigned, which can then be
converted to signed with a proc like this:

length = 16
max = 2length-1
mid = 2(length-1)
to_signed = proc {|n| (n >= mid) ? -((n ^ max) + 1) : n}

It seems reasonable to add a format specifier to do this directly.
Thoughts?

2

[email protected] wrote:

It seems reasonable to add a format specifier to do this directly.
Thoughts?

I’d vote for that. Looks like you already found this thread :slight_smile:

http://blade.nagaokaut.ac.jp/cgi-bin/vframe.rb/ruby/ruby-talk/165774?165771-168359

3

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.

4

On Mar 30, 2006, at 1:38 PM, [email protected] wrote:

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):

[…]

I’m thinking of submitting an RCR for this,

Don’t bother with an RCR, just submit a patch to ruby-core.

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.

What does perl or python do for the same types?

–
Eric H. - [email protected] - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com

5

On Fri, 31 Mar 2006, [email protected] wrote:

tried to come up with consistent mappings based on what already exists
I unsigned native int
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 :wink:
that said
they are extremely useful.

good luck.

-a

6

Hi,

In message “Re: unpack signed short in network (big-endian) byte order”
on Fri, 31 Mar 2006 08:08:43 +0900, “[email protected]”
[email protected] writes:
|
|Perl’s pack options seem to be largely the same. It has the same holes
|that ruby does. One interesting wrinkle is that where ruby uses the
|underscore (“_”) suffix to enforce native lengths, perl uses a bang
|(“!”). I don’t know why that’s different.

Since Perl used to use underscore when I implemented it. Besides Ruby
allows “!” as well.

						matz.
7

Yukihiro M. wrote:

|Perl’s pack options seem to be largely the same. It has the same holes
|that ruby does. One interesting wrinkle is that where ruby uses the
|underscore ("_") suffix to enforce native lengths, perl uses a bang
|("!"). I don’t know why that’s different.

Since Perl used to use underscore when I implemented it. Besides Ruby
allows “!” as well.

Oh? I don’t think that’s mentioned in the rdoc for pack/unpack. In any
case, do you have any thoughts about adding these other formats?

8

Perl’s pack options seem to be largely the same. It has the same holes
that ruby does. One interesting wrinkle is that where ruby uses the
underscore (“_”) suffix to enforce native lengths, perl uses a bang
(“!”). I don’t know why that’s different.

http://www.xav.com/perl/lib/Pod/perlfunc.html#item_pack

Python has a rather different approach. There are only a few specifiers
but integer length and byte-order are defined by a modifier at the
front of the format string.

I sort of like the Python idea, because then we wouldn’t have to
introduce more cryptic format specifiers. However, it eliminates the
(potentially unlikely) ability to have different byte-ordering for
different values within the array being packed. Perhaps the best
solution is to allow the modifier at the beginning to establish a
default, but allow modifiers after specifiers as well in order to
override the default. On the other hand, maybe it would be best to
stick to one or the other approach. The former is simpler and probably
covers the common usage, but the latter is more similar to the way the
function currently works.

I don’t know. Opinions?

9

Hi,

In message “Re: unpack signed short in network (big-endian) byte order”
on Fri, 31 Mar 2006 06:38:43 +0900, “[email protected]”
[email protected] writes:

|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):

The pack templates are derived from Perl, and I don’t want to add our
own templates. I just talked with Larry Wall who gave presentation at
YAPC::Asia Tokyo, and he said he was not sure how to deal pack
templates in Perl6 yet. Maybe we can meet agreement to add new pack
templates, or we can think of other feature to pack/unpack binary
data, such as cstruct module in Python.

						matz.
10

Oops, ‘y’ can’t be both signed network long and signed little-endian
long. How about this:

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
O ? signed network long
V unsigned little-endian long
R ? signed little-endian long