Hi Holger, sorry, I'm not good at responding to unsorted email in a timely manner :/
The comment is inaccurate, the wraparound relates to how the number is used in OID >> #initialize, not the number itself. lp := LargePositiveInteger new: 3. lp at: 1 put: 255; at: 2 put: 255; at: 3 put: 255. lp := lp digitAdd: 1. (ByteArray new: 3) replaceFrom: 1 to: 3 with: lp startingAt: 1; yourself So the number will keep on growing, but for the purposes of our use, it wraps around. Cheers, Henry > On 30 May 2016, at 9:57 , Holger Freyther <hol...@freyther.de> wrote: > > Hi, > > I tried to reach the author for several weeks but he doesn't seem to respond > so I am trying to reach a wider audience to either confirm my suspicion or to > be corrected. In > http://smalltalkhub.com/#!/~MongoTalkTeam/mongotalk/diff/Mongo-BSON-HenrikSperreJohansen.43 > > the following change is done: > > + "digitAdd: wraps around to 0 when result would overflow" > + ^ counter := counter > + ifNil:[self newCounter] > + ifNotNil:[counter digitAdd: 1]! > - ^ counter := (counter + 1) \\ 16rFFFFFF! > > The old code has overflow checking, the new code makes a statement I don't > think is true. counter is LargePositiveInteger new: 3 to use three bytes. So > given the above code and the experiment (yes I could just add a bigger number) > > | id | > id := LargePositiveInteger. > 1 to: (16777215 + 50) do: [:each | > id := id digitAdd: 1]. > id. > > Given the comment it should overflow and the value be 50? This is not what > the result is. So shall the truncation be added again or at least the comment > be updated? The code will go from LargePositiveInteger to SmallInteger when > overflowing from three to four bytes but luckily > >>> #value > ... > replaceFrom: 1 to: 3 with: self class counterNext startingAt: 1 > > will even work when counterNext returns a SmallInteger. But given the old > code and the comment in the new code this is does not seem to function as > intended? > > kind regards > holger > > > PS: The other part is that >>#newCounter doesn't seem to be ever executed. On > first load >>#initialize will call >>#reset and on >>#shutDown: calls reset. > So the code to "randomize" the initial counter doesn't seem to work. > >
signature.asc
Description: Message signed with OpenPGP using GPGMail