binaryEncode/binaryDecode (was Re: Endian conversion problems)

[Dar Scott]

On Wednesday, August 6, 2003, at 03:37 PM, David Beck wrote:

> Basically these two functions are a mess. The documentation is flat out
> wrong and even if it were correct they would still be a mess.
>
> for binaryEncode:
>
> the 'n' format is documented as encoding a number string into a signed
> 2-byte integer in network byte order. The 'N' format is documented to 
> do the
> same thing for a 2-byte unsigned integer in network byte order.
>
> This is wrong.

I think the documentation should say N is signed.  This is consistent 
with Perl formats.  This has been reported to bugzilla and brought up 
on the improve-revolution discussion list.

> The 'n' format will convert signed OR unsigned values into a 2-byte 
> integer
> in network byte order, and the 'N' format will convert signed or 
> unsinged
> values into a 4-byte integer in network byte order.

Do you think an error should occur if the number is outside the signed 
range?  What should happen?  I don't have a strong feeling as to this.  
I have suggested an unsigned big endian format be added.


> This function works consistently regardless of whether you are running 
> on a
> Mac or Windows machine.

Oh, good.


> for binaryDecode:
>
> The 'n' format is documented to convert signed big endian 2-byte 
> binary data
> into a number string. This works as documented on the Mac side, but if 
> I
> build a standalone for Windows, the 'n' flag starts converting the same
> 2-bytes as unsigned 2-byte data.

Yikes!

> The 'N' format is documented to convert unsigned 2-byte binary data in
> network byte order, but actually converts 4-byte binary data in 
> network byte
> order as signed data if it is on the mac side, and unsigned data if it 
> is on
> the window side.

Yikes!

I see these as a single Windows bug, given the assumption that that N 
should be signed.  If you don't bugzilla it, I'll play with this and 
see what happens.  (My PC has been ill and only now am I getting back 
to it.)

> I know the 'I' (uppercase i) flag has similar problems, as I would 
> guess the
> 's' flag does, but I didn't go there since I didn't have to.

Do you mean signed vs. unsigned problems?  That's a bug.  If you mean 
byte-order, well, I is host dependent.

> Please fix these functions and their documentation!!

Does this summary seem correct?

1.  The documentation shows N as unsigned and it should be signed.  
(reported)
2.  binaryEncode() for is too tolerant in range checking and should 
create errors.
3.  Windows has signed/unsigned wrong for at least three formats.

You might want to bugzilla a suggestion for #2.  You should report a 
bug for #3 (or if you prefer, help me see it and I'll report the bug).

I'm with you.  I'm eager to encourage RunRev to keep these formats in 
good shape.

Dar Scott