Dominique Pellé wrote:
> Tony Mechelynck <[email protected]> wrote:
>
> > After applying patches (8.1.) 953 to 956 I get the following warning
> > in Tiny and Small builds (only):
> >
> > gcc -c -I. -Iproto -DHAVE_CONFIG_H -O2 -fno-strength-reduce -Wall
> > -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -o objects/ex_cmds.o
> > ex_cmds.c
> > ex_cmds.c: In function ‘ex_sort’:
> > ex_cmds.c:557:43: warning: overflow in implicit constant conversion
> > [-Woverflow]
> > nrs[lnum - eap->line1].st_u.value = -MAXLNUM;
> > ^
>
> I can reproduce it indeed with tiny builds with 8.1.0953
> and beyond.
>
> When pre-processing, the line where it warns is:
>
> nrs[lnum - eap->line1].st_u.value = -0x7fffffffffffffffL;
>
> Type of expression on the left (st_u.value) is varnumber_T
> which is defined in struct.h:1219 as:
> - 'int' when FEAT_NUM64 is not defined
> - a 64-bits type when FEAT_NUM64 is defined.
>
> I don't know why -MAXLNUM is used here as it st_u.value
> does not seem to contain a line number. It seems wrong.
> Maybe -VARNUM_MAX was meant to be used as follows
> (or perhaps VARNUM_MIN?):
>
> diff --git a/src/ex_cmds.c b/src/ex_cmds.c
> index da10c1291..baa65d040 100644
> --- a/src/ex_cmds.c
> +++ b/src/ex_cmds.c
> @@ -554,7 +554,7 @@ ex_sort(exarg_T *eap)
> --s; /* include preceding negative sign */
> if (*s == NUL)
> /* empty line should sort before any number */
> - nrs[lnum - eap->line1].st_u.value = -MAXLNUM;
> + nrs[lnum - eap->line1].st_u.value = -VARNUM_MAX;
> else
> vim_str2nr(s, NULL, NULL, sort_what,
> &nrs[lnum - eap->line1].st_u.value, NULL, 0);
>
> It looks like this was a silent bug in :sort even before 8.1.0953
> when FEAT_NUM64 was defined as -0x7fffffff was then assigned
> to a 64-bits number which looks suspicious. It should be possible
> to find a case where :sort was misbehaving.
>
> Dominique
I see that behavior of :sort n' was wrong
both before and after 8.1.953 but in different
ways in vim huge as well as in Vim tiny, it was
also wrong before and after 8.1.953.
Example with vim tiny >= 8.1.953
$ cat > numbers.txt <<EOF
1
-1
0
2147483647
2147483647
2147483646
-2147483648
-2147483647
-2147483646
EOF
$ vim-8.1.956.tiny --clean numbers.txt -c 'sort n'
gives:
===
-2147483648
-2147483647
-2147483646
-1
0
1
2147483646
2147483647
2147483647
===
Prior to 8.1.953, vim.tiny was also sorting
incorrectly but differently as:
===
2147483648
-2147483647
-2147483646
-1
0
1
2147483646
2147483647
2147483647
===
Now when applying the following patch...
diff --git a/src/ex_cmds.c b/src/ex_cmds.c
index da10c1291..3cb4641e8 100644
--- a/src/ex_cmds.c
+++ b/src/ex_cmds.c
@@ -554,7 +554,7 @@ ex_sort(exarg_T *eap)
--s; /* include preceding negative sign */
if (*s == NUL)
/* empty line should sort before any number */
- nrs[lnum - eap->line1].st_u.value = -MAXLNUM;
+ nrs[lnum - eap->line1].st_u.value = VARNUM_MIN;
else
vim_str2nr(s, NULL, NULL, sort_what,
&nrs[lnum - eap->line1].st_u.value, NULL, 0);
I then get the expected output with vim.tiny:
===
-2147483648
-2147483647
-2147483646
-1
0
1
2147483646
2147483647
2147483647
===
However, ordering of empty lines
and -2147483648 are treated the same and
ordering is thus sometimes wrong as in this
example:
$ cat > numbers.txt <<EOF
1
-1
0
-2147483648
2147483647
2147483647
2147483646
-2147483648
-2147483647
-2147483646
EOF
Which gets ordered as:
===
2147483648
-2147483648
-2147483647
-2147483646
-1
0
1
2147483646
2147483647
2147483647
===
I'll see how this can be improved.
Dominique
--
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
