[vim/vim] Decrementing 2**64 gives wrong result (Issue #12103)
15 views
Skip to first unread message
James McCoy
Mar 4, 2023, 11:52:13 AM3/4/23
to vim/vim, Subscribed
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
Version of Vim
9.0.1378
Environment
Debian/sid
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Mar 4, 2023, 3:47:52 PM3/4/23
to vim/vim, Subscribed
> ### Steps to reproduce
>
> Create a buffer with the number `18446744073709551616`.
> Press `Ctrl-x` with the cursor on the number.
>
> ### 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.
--
hundred-and-one symptoms of being an internet addict:
223. You set up a web-cam as your home's security system.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Mar 4, 2023, 3:48:21 PM3/4/23
to vim/vim, Subscribed
Closed #12103 as completed via 5fb78c3.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marvin Renich
Mar 5, 2023, 12:09:27 PM3/5/23
to vim...@googlegroups.com, reply+ACY5DGAKOAHTZV6QKU...@reply.github.com
* Bram Moolenaar <vim-dev...@256bit.org> [230304 15:47]:
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
>
> > ### 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
> > ### 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.
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
vim-dev ML
Mar 5, 2023, 4:16:01 PM3/5/23
to vim/vim, vim-dev ML, Your activity
Marvin Renich wrote:
> * Bram Moolenaar ***@***.***> [230304 15:47]:
> >
> > > ### Steps to reproduce
> > >
> > > Create a buffer with the number `18446744073709551616`.
> > > Press `Ctrl-x` with the cursor on the number.
> > >
> > > ### 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.
how this can ever do what the user wants.
Using arbitrary precision can work, but it would require a lot of
changes in the code. Currently CTRL-A and CTRL-X use functions common
to other commands, it would have to be split and quite a bit of code
needs to be duplicated. Including handling of hex and octal numbers.
I doubt this is used often enough to justify the work.
--
A computer without Windows is like a fish without a bicycle.
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marvin Renich
Mar 6, 2023, 7:34:05 AM3/6/23
to reply+ACY5DGDVZMT3TYC7RC...@reply.github.com, vim...@googlegroups.com
* vim-dev ML <vim-dev...@256bit.org> [230305 16:16]:
I don't see how decrementing 18446744073709551618 and getting
18446744073709551615 could be what the user wants, either. Incrementing
18446744073709551615 and getting -18446744073709551615 is also
unexpected (for pure math) but correct (for 64-bit arithmetic). I'll
agree that hooking up arbitrary precision may not be worth the effort.
I think the best compromise is to have a consistent and documented
behavior for numbers not representable by 64-bit signed ints. The
behavior before you made this change appears to be to treat all
positive, too-large numbers as the largest representable number (for
both increment and decrement) and all negative, too-small numbers as the
smallest representable number for both increment and decrement.
After your change (I'm going by your description; I haven't built a new
vim to test it), it seems you treat too-large numbers as one more than
the largest representable number (2^64) for decrement but as 2^64-1 for
increment, and similarly for too-small numbers.
This moves the seemingly anomalous behavior by one (18446744073709551616
gives the correct result for decrement, but 18446744073709551617 gives a
result that is off by one), at the expense of requiring more verbiage to
explain, and treating increment and decrement of out-of-range values
differently.
I think the previous behavior is more consistent and easier to explain
and justify. Either way has values which give very close, but wrong
(for pure math) results. If arbitrary precision is not worth the
effort, I would stick with the previous behavior and document it.
...Marvin
18446744073709551615 could be what the user wants, either. Incrementing
18446744073709551615 and getting -18446744073709551615 is also
unexpected (for pure math) but correct (for 64-bit arithmetic). I'll
agree that hooking up arbitrary precision may not be worth the effort.
I think the best compromise is to have a consistent and documented
behavior for numbers not representable by 64-bit signed ints. The
behavior before you made this change appears to be to treat all
positive, too-large numbers as the largest representable number (for
both increment and decrement) and all negative, too-small numbers as the
smallest representable number for both increment and decrement.
After your change (I'm going by your description; I haven't built a new
vim to test it), it seems you treat too-large numbers as one more than
the largest representable number (2^64) for decrement but as 2^64-1 for
increment, and similarly for too-small numbers.
This moves the seemingly anomalous behavior by one (18446744073709551616
gives the correct result for decrement, but 18446744073709551617 gives a
result that is off by one), at the expense of requiring more verbiage to
explain, and treating increment and decrement of out-of-range values
differently.
I think the previous behavior is more consistent and easier to explain
and justify. Either way has values which give very close, but wrong
(for pure math) results. If arbitrary precision is not worth the
effort, I would stick with the previous behavior and document it.
...Marvin
vim-dev ML
Mar 6, 2023, 7:34:27 AM3/6/23
to vim/vim, vim-dev ML, Your activity
* vim-dev ML ***@***.***> [230305 16:16]:
> Marvin Renich wrote:
> > * Bram Moolenaar ***@***.***> [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`
> Marvin Renich wrote:
> > * Bram Moolenaar ***@***.***> [230304 15:47]:
> > >
> > > >
> > > > Create a buffer with the number `18446744073709551616`.
> > > > Press `Ctrl-x` with the cursor on the number.
> > > >
> > > > ### Expected behaviour
> > > >
> > > > Number is changed to `18446744073709551615`
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
vim-dev ML
Mar 6, 2023, 3:15:49 PM3/6/23
to vim/vim, vim-dev ML, Your activity
Marvin Renich wrote:
> > > * Bram Moolenaar ***@***.***> [230304 15:47]:
> > > >
> > > > >
> > > > > Create a buffer with the number `18446744073709551616`.
> > > > > Press `Ctrl-x` with the cursor on the number.
A problem with documenting this as the intended behavior is that it
blocks making it work properly some day. It's probably better to
say this is undefined behavior, and mentioning what most systems
currently do. But it's mainly an execuse, I don't expect users to read
this before they notice the behavior. Just for us to say it's not a bug
because it's documented.
> After your change (I'm going by your description; I haven't built a new
> vim to test it), it seems you treat too-large numbers as one more than
> the largest representable number (2^64) for decrement but as 2^64-1 for
> increment, and similarly for too-small numbers.
number, but the addition or subtraction is not done.
> This moves the seemingly anomalous behavior by one (18446744073709551616
> gives the correct result for decrement, but 18446744073709551617 gives a
> result that is off by one), at the expense of requiring more verbiage to
> explain, and treating increment and decrement of out-of-range values
> differently.
> I think the previous behavior is more consistent and easier to explain
> and justify. Either way has values which give very close, but wrong
> (for pure math) results. If arbitrary precision is not worth the
> effort, I would stick with the previous behavior and document it.
not what users expect to happen. The rest of the discussion is
speculating what would be the least-worst solution. In cases like this
would rather go with an actual complaint than speculation.
It is true that any computation that has a result which is wrong can be
considered a problem. Other than the actual (but expensive) fix we
could give a warning, so the user knows the result isn't exactly right.
--
You are Dead. Do you wish to restart, load, or quit?
/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Marvin Renich
Mar 6, 2023, 3:43:59 PM3/6/23
to reply+ACY5DGCW5XCWOYJACV...@reply.github.com, vim...@googlegroups.com
* Bram Moolenaar [230306 15:15]:
happy with it.
> I would think that "2 ** 64" appears much more often than "2 ** 64 + 1".
Perhaps, or perhaps someone was just testing edge conditions.
> For the old behavior a bug was reported, which is an indication it is
> not what users expect to happen. The rest of the discussion is
> speculating what would be the least-worst solution. In cases like this
> would rather go with an actual complaint than speculation.
That's a perfectly reasonable approach.
Thanks for listening to my arguments for a different solution and
helping me understand the reasoning behind your solution.
...Marvin
> Marvin Renich wrote:
> > After your change (I'm going by your description; I haven't built a new
> > vim to test it), it seems you treat too-large numbers as one more than
> > the largest representable number (2^64) for decrement but as 2^64-1 for
> > increment, and similarly for too-small numbers.
>
> Not exactly. The number is rounded off to the nearest representable
> number, but the addition or subtraction is not done.
Ah, okay. This is an easily documentable and consistent behavior. I'm
> > After your change (I'm going by your description; I haven't built a new
> > vim to test it), it seems you treat too-large numbers as one more than
> > the largest representable number (2^64) for decrement but as 2^64-1 for
> > increment, and similarly for too-small numbers.
>
> Not exactly. The number is rounded off to the nearest representable
> number, but the addition or subtraction is not done.
happy with it.
> I would think that "2 ** 64" appears much more often than "2 ** 64 + 1".
> For the old behavior a bug was reported, which is an indication it is
> not what users expect to happen. The rest of the discussion is
> speculating what would be the least-worst solution. In cases like this
> would rather go with an actual complaint than speculation.
Thanks for listening to my arguments for a different solution and
helping me understand the reasoning behind your solution.
...Marvin
vim-dev ML
Mar 6, 2023, 3:44:15 PM3/6/23
to vim/vim, vim-dev ML, Your activity
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
Mar 7, 2023, 10:57:03 AM3/7/23
to vim...@googlegroups.com, Marvin Renich, reply+ACY5DGAKOAHTZV6QKU...@reply.github.com
[not sure if this got through, ignore if you already have seen it]
Marvin Renich wrote:
> * Bram Moolenaar <vim-dev...@256bit.org> [230304 15:47]:
Using arbitrary precision can work, but it would require a lot of
changes in the code. Currently CTRL-A and CTRL-X use functions common
to other commands, it would have to be split and quite a bit of code
needs to be duplicated. Including handling of hex and octal numbers.
I doubt this is used often enough to justify the work.
--
A computer without Windows is like a fish without a bicycle.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
changes in the code. Currently CTRL-A and CTRL-X use functions common
to other commands, it would have to be split and quite a bit of code
needs to be duplicated. Including handling of hex and octal numbers.
I doubt this is used often enough to justify the work.
--
A computer without Windows is like a fish without a bicycle.
vim-dev ML
Mar 7, 2023, 10:57:19 AM3/7/23
to vim/vim, vim-dev ML, Your activity
[not sure if this got through, ignore if you already have seen it]
Marvin Renich wrote:
> * Bram Moolenaar ***@***.***> [230304 15:47]:
> >
> > > ### Steps to reproduce> >
> > >
> > > Create a buffer with the number `18446744073709551616`.
> > > Press `Ctrl-x` with the cursor on the number.
> > >
> > > ### Expected behaviour
> > >
> > > Number is changed to `18446744073709551615`
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Reply all
Reply to author
Forward
0 new messages