In order to generate INT64_MIN from literal values, it's necessary to
use "-0x7fffffffffffffff - 1". Using "-0x8000000000000000" causes the
value to get clamped to INT64_MAX and then negated.
If if the resolved $NVIM_LOG_FILE *and* stdpath("data")/log cannot be
created (e.g. because the XDG data directory does not exist), fall back
to .nvimlog in the current direcrtory.
- Do not delete it: may need to inspect it after tests finished.
- Avoids writing to stderr in cases where the test-local $XDG_DATA_HOME
was not created yet.
- Establish ERROR log level as "critical". Such errors are rare and will
be valuable when users encounter unusual circumstances.
- Set -DMIN_LOG_LEVEL=3 for release-type builds
Problem: float2nr() is not exactly right.
Solution: Make float2nr() more accurate. Turn test64 into a new style test.
(Hirohito Higashi, closesvim/vim#1688)
863e80b445
Problem: Using :change in between :function and :endfunction fails.
Solution: Recognize :change inside a function. (ichizok, closesvim/vim#1374)
70bcd7336f
Problem: str2nr() and str2float() do not always work with negative values.
Solution: Be more flexible about handling signs. (LemonBoy, closesvim/vim#1332)
Add more tests.
08243d26d2
Problem: On MS-Windows some float functions return a different value when
passed unusual values. strtod() doesn't work for "inf" and "nan".
Solution: Accept both results. Fix str2float() for MS-Windows. Also
reorder assert function arguments.
6247361101
This is a new convention pioneered by tmux. It does not do much for
nvim; since nvim always looks to see whether it should be making up
"setrgbf" and "setrgbb" capabilities. But it is a way for terminfo to
force this, irrespective of the hardwired list in the code, for more
terminal types. On the gripping hand, updating terminfo descriptions to
actually have "setrgbf" and "setrgbb" capabilities so that nvim never
has to try to invent them in the first place, is as good if not better
an approach for overriding what is baked into the code.
After merging +num64, the 64-bit sanitizer builds show that Vim doesn't
buffer the user from C's UB in signed arithmetic. Upstream doesn't
appear to be [interested] in fixing the issue, so suppress UBSAN until
someone decides to fix the problem.
N.B., the problem existed before but went unnoticed since the sanitizer
builds weren't being run in 32-bit mode.
[interested]: https://groups.google.com/d/topic/vim_dev/_tqf8eQy5eA/discussion
Problem: Ubsan reports errors for integer overflow.
Solution: Define macros for minimum and maximum values. Select an
expression based on the value. (Mike Williams)
7a40ea2138
Problem: Compiler warnings with older compiler and 64 bit numbers.
Solution: Add "LL" to large values. (Mike Williams)
af9c4c9b57
Equivalent change was made in ZyX's typval refactoring.
Problem: Compiler warns for loss of data.
Solution: Use size_t instead of int. (Christian Brabandt)
fef524bbff
Equivalent change had already been made when merging earlier pack
patches.
Problem: With 64 bit changes don't need three calls to sprintf().
Solution: Simplify the code, use vim_snprintf(). (Ken Takata)
bde9810d61
nvim already had the equivalent code, so only the patch number was
needed.
Problem: On MS-Windows large files (> 2Gbyte) cause problems.
Solution: Use "off_T" instead of "off_t". Use "stat_T" instead of "struct
stat". Use 64 bit system functions if available. (Ken Takata)
8767f52fbf
Only the off_T changes are relevant, since all the "struct stat" usage
is abstracted by libuv.
