[squeak-dev] ByteArray accessors - questions about some of the accessors

David T. Lewis lewis at mail.msen.com
Wed Sep 9 16:17:17 UTC 2015


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
>
>




More information about the Squeak-dev mailing list