binaryEncode/binaryDecode (was Re: Endian conversion problems)

Dar Scott dsc at swcp.com
Wed Aug 6 17:33:14 EDT 2003


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




More information about the use-livecode mailing list