Closes#4370
Explication:
In the backtrace in #4370, we see that `buf_write()` was called with
non-NULL `fname` and `sfname` arguments, but they've since _become_
NULL.
#7 0x00000000004de09d in buf_write (buf=0x1dee040, fname=0x0, fname@entry=0x1e985b0 "/home/sean/src/github.com/snczl/virta/pkg/meld/segment.go",
sfname=0x0, sfname@entry=0x1ddfa60 "segment.go", start=1, end=72, eap=eap@entry=0x7ffc6b032e60, append=0,
forceit=0, reset_changed=1, filtering=0)
at /home/travis/build/neovim/bot-ci/build/neovim/src/nvim/fileio.c:2576
This is most likely due to the code that restores those values from
`buf`, which happens just before the fatal call to `os_fileinfo`
```c
/*
* The autocommands may have changed the name of the buffer, which may
* be kept in fname, ffname and sfname.
*/
if (buf_ffname)
ffname = buf->b_ffname;
if (buf_sfname)
sfname = buf->b_sfname;
if (buf_fname_f)
fname = buf->b_ffname;
if (buf_fname_s)
fname = buf->b_sfname;
```
It's worth noting that at this point `ffname` is still non-NULL, so
it _could_ be used. However, our current code is purely more strict
than Vim in this area, which has caused us problems before (e.g.,
`getdigits()`). The commentary for `struct file_buffer` clearly
indicate that all of `b_ffname`, `b_sfname`, and `b_fname` may be
NULL:
```c
/*
* b_ffname has the full path of the file (NULL for no name).
* b_sfname is the name as the user typed it (or NULL).
* b_fname is the same as b_sfname, unless ":cd" has been done,
* then it is the same as b_ffname (NULL for no name).
*/
char_u *b_ffname; /* full path file name */
char_u *b_sfname; /* short file name */
char_u *b_fname; /* current file name */
```
Vim directly calls `stat(2)` which, although it is annotated to tell
the compiler that the path argument is non-NULL, does handle a NULL
pointer by returning a `-1` value and setting `errno` to `EFAULT`.
This satisfies Vim's check, since it treats any `-1` return from
`stat(2)` to mean the file doesn't exist (at least in this code
path).
Note that Vim's mch_stat() implementations on win32 and solaris
clearly cannot accept NULL `name`. But the codepaths that call
mch_stat will NULL `name` tend to be unix-only (eg: u_read_undo)!
Running this test with a mocked passwd file whose $HOME was set to
/home/jamessan/src/debian.org/pkg-vim/deb-packages/neovim/neovim-0.2.0/debian/fakehome
caused the test to fail, since the expanded result was >= 99 bytes. The
test should be reflecting the actual size of the buffer, instead of some
arbitrary other number, anwyay.
Not using enum{} because SIZE_MAX exceeds integer and I do not really like how
enum definition is described in C99:
1. Even though all values must fit into the chosen type (6.7.2.2, p 4) the type
to choose is still implementation-defined.
2. 6.4.4.3 explicitly states that “an identifier declared as an enumeration
constant has type `int`”. So it looks like “no matter what type was chosen
for enumeration, constants will be integers”. Yet the following simple
program:
#include <stdint.h>
#include <stdio.h>
#include <stddef.h>
enum { X=SIZE_MAX };
int main(int argc, char **argv)
{
printf("x:%zu m:%zu t:%zu v:%zu",
sizeof(X), sizeof(SIZE_MAX), sizeof(size_t), (size_t)X);
}
yields one of the following using different compilers:
- clang/gcc/pathcc: `x:8 m:8 t:8 v:18446744073709551615`
- pcc/tcc: `x:4 m:8 t:8 v:1844674407370955161`
If I remove the cast of X to size_t then pcc/tcc both yield `x:4 m:8 t:8
v:4294967295`, other compilers’ output does not change.
All compilers were called with `$compiler -std=c99 -xc -` (feeding program
from echo), except for `tcc` which has missing `-std=c99`. `pcc` seems to
ignore the argument though: it is perfectly fine with `-std=c1000`.
Some benchmarks:
MAIN_CDEFS + NO_TRACE: 3.81s user 1.65s system 33% cpu 16.140 total
MAIN_CDEFS: 73.61s user 10.98s system 154% cpu 54.690 total
NO_TRACE: 18.49s user 4.30s system 73% cpu 30.804 total
(default): 77.11s user 14.74s system 126% cpu 1:12.79 total
Also fixes incorrect location of `tv_dict_add` function and three bugs in other
functions:
1. `tv_dict_add_list` may free list it does not own (vim/vim#1555).
2. `tv_dict_add_dict` may free dictionary it does not own (vim/vim#1555).
3. `tv_dict_add_dict` ignores `key_len` argument.
Additional modifications:
- More `const` qualifiers in tested functions.
- `tv_list_find_str()` second argument is more in-line with other
`tv_list_find*()` functions.
Tests crash at some point without
- `after_each(collectgarbage)` right before “typval.c list copy() copies list
correctly and converts items” test.
- Commenting out that test.
- Adding `collectgarbage()` after the test (what actually this commit does).
Adding `collectgarbage()` to top-level `after_each` block right after
`restore_allocators` makes running this file crash even if it is run alone.
Also found some bugs:
1. var_item_copy() always fails to copy v:_null_list and v:_null_dict. Fixing
this should mean fixing `deepcopy(v:_null_list)` which should’ve been, but
was not listed in #4615. This also fixes `deepcopy(v:_null_dict)`.
2. var_item_copy() crashes when trying to copy NULL string with `conv != NULL`.
3. `conv` argument is ignored when copying list unless `deep` is true, but it
was not reflected in documentation.
4. `tv_dict_item_alloc_len()` allocated more memory then needed.
5. typvalt2lua was not able to handle self-referencing containers.
The directory name could contain special characters that trips up the
matching used by find. Instead, let's just make sure that the filename
starts with the directory name.
Used
sed -r -i -e '/ helpers =/ s/$/\nlocal itp = helpers.gen_itp(it)/; s/^(\s*)it\(/\1itp(/' test/unit/**/*_spec.lua
to alter all tests. Locally they all run fine now.
Reasoning:
1. General: state from one test should not affect other tests.
2. Local: travis build is failing with something which may be an output of
garbage collector. This should prevent state of the garbage collector from
interferring as well.
