These methods don't validate their arguments, just like most other 
Smalltalk methods. I'm pretty sure the unsigned*put* methods would accept 
LargeNegativeIntegers as input. The same applies to the signed methods 
with larger than acceptable inputs (e.g. shortAt:put:bigEndian: will 
accept 65535 and store it as if it were -1).

Levente

On Wed, 9 Sep 2015, David T. Lewis wrote:

> Hi Chris,
>
> I have not been following these updates too closely, but I can say without
> hesitation that using -1 as shorthand for 16rff or 16rffff (or whatever)
> in the context of unsigned integer fields would be a bad thing to do, and
> if our accessors are treating it as an error, then that is good.
>
> It might be good to document this in the form of unit tests that explain
> that the failure is intentional.
>
> Dave
>
>> 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
>>
>>
>
>
>
>