* Bram Moolenaar <vim-dev-git...@256bit.org> [230304 15:47]: > > > ### Steps to reproduce > > > > Create a buffer with the number `18446744073709551616`. > > Press `Ctrl-x` with the cursor on the number. > > Number is changed to `18446744073709551614`. > > > > ### Expected behaviour > > > > Number is changed to `18446744073709551615` > > The problem is that 2 ** 64 does not fit in the variable being used. > Getting the number from the text results in the maximum number that can > be represented, which is 18446744073709551615. Then one is subtracted. > > I think the best we can do is keep a flag for the "overflow" and then > not subtract one. That makes this corner case work, although it won't > be fixed in the general case. Still better than doing nothing.
I don't think this is the right fix. I think you should either document that 64-bit arithmetic is being used, and load the original number as 0 (the correct modulo-64 representation) and decrement gives -1 and increment gives 1, or decide to use arbitrary-precision arithmetic and give the correct answer for numbers larger than 2^64. Either of these two approaches give consistent results for numbers larger than 2^64-1, whereas the fix you suggest only makes one 'out-of-bounds' value work. I would prefer the current behavior to applying the fix you are suggesting. I would be willing to write the arbitrary-precision code so that no external library need be used, but I might not get to it right away. ...Marvin -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/ZATMw7uo9w/xcfcs%40basil.wdw.
