Hi.

First and foremost, this is not about an issue caused by the recent
enhancements to the ByteArray accessors for 64-bit manipulation, but rather
a series of questions that has been brewing in my mind during the
discussions.

I notice that I can't pass negative numbers to the various
#unsigned..At:put:bigEndian:  methods.  While this may be on purpose (since
they are UNSIGNED), it is still annoying.  I happen to know that our
numbers are stored roughly two-complement, meaning that -1 is the same as
16rFF, 16rFFFF, 16rFFFFFFFF, etc - whatever size I choose (since our digits
are never end - we essentially have a infinite length twos compliment
negative numbers).  Yet I can't store them with the unsigned, getting an
improper store each time I try.  All of these fail:

ba at: 1 put: -1
ba unsignedShortAt: 1 put: -1 bigEndian: false
ba unsignedLongAt: 1 put: -1 bigEndian: false
ba unsignedLong64At: 1 put: -1 bigEndian: false

Is this intentional, and I should stop trying to abuse the methods?  If so,
I'll stop.

Still:

ba at: 1 put: -1
ba shortAt: 1 put: -1 bigEndian: false
ba longAt: 1 put: -1 bigEndian: false
ba long64At: 1 put: -1 bigEndian: false

Only the second and third of the above work- we haven't yet added the
fourth one, and apparently we signed byte access has never been there.
 (And there are uses of signed bytes out there - google it - but I have not
personally needed it.  Still, we could/should be complete.)

The other issue found (by accident) is that #longAt:put:bigEndian and
#unsignedLongAt:put:bigEndian: allow for arbitrarily large numbers to be
passed to them - way bigger than 32 bits - and stores the end 32 bits off
of them to the array.  (Except you can't pass SOME negative numbers like -1
to #unsignedLongAt:put:bigEndian: - go figure).  This should be fixed - but
it is a very long-standing bug.

-cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20150909/2ae7adfd/attachment.htm