>>>I expected that the result of bintoc(0,1) would be chr(0) - in fact it is chr(128), or 80 hex. Further tests showed that all bintoc() results have 128 added to the most significant byte.
>>>Ex:
>>>bintoc(255) results in chr(128)+chr(255) (hex 80 FF)
>>>bintoc(256) results in chr(129)+chr(0) (hex 81 00)
>>>
>>>Why is this?
>>>
>>Doru,
>>
>>What's happening is that the values are being translated so that when you do a direct character comparison between two, the results are the same as if they were actually integers.
>>
>>In order to achieve this, because of the way strings are compared, the order of the bytes are first reversed. The following shows how these are stored in memory and then after a call to BINTOC()

255 Memory - FF 00 Character - 80 FF
>>256 Memory - 00 01 Character - 81 00

This is because, as integer the values are stored as least to most significant byte order.
>>
>>Now what about that extra 0x80 in both? The most significant bit with a signed integer is the sign. If the bit is set, the value is negative, if not, positive. However, with strings this would cause the value to be improperly evaluated. IOW, negatives would come after positives. So in order to deal with the signs, the state of the most signifcant bit is reversed as well. Set for positive, clear for negative.
>>Memory
>
>Hi George,
>Absolutely fox team had good reason to do it that way. I wonder why they didn't simply use char representation from 0 to 0xFFFFFFFF (unsigned). IMHO string comparison would be in order + we wouldn't need checks when we used it for some other purpose.

Cetin,

If I had to offer a SWAG on the reason, it would be because all true integers in VFP are signed.

? BITOR(0xFFFFFFFF, 0)