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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
