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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to