Attempting to serialize a NULL string through msgpack results in
msgpack_sbuffer_write attempting to memcpy from a NULL pointer, which is
undefined behavior.
move `call_shell` to misc1.c
Move some fns to state.c
Move some fns to option.c
Move some fns to memline.c
Move `vim_chdir*` fns to file_search.c
Move some fns to new module, bytes.c
Move some fns to fileio.c
Previously there was file descriptor leak, not detected by sanitizers. Now it is
file descriptor leak with a small memory leak which is detected by ASAN what
fails one of the tests (actually, “ShaDa support code leaves .tmp.z in-place
when there is error in original ShaDa and it has .tmp.a … .tmp.x”, but error is
reported at the next test because leaks are not detected until Neovim exit and
Neovim exit happens when clear()/reset() is called which happens in before_each
only).
One of the reasons is that O_RDONLY is zero, which makes checking whether file
is opened read- or write-only harder. It is not guaranteed that on other system
O_WRONLY will not be zero (e.g. because file can only be opened in read-write
mode).
Moves low-level functions handling to os/fs.c. Adds file.c with a proxy
interface.
Target: while leaving syscalls handling is os.c (partially handled by libuv),
add buffering for reading and writing to file.c.
This was noticed due to a user issue (#4750) when building Neovim 0.1.4
via ports. The crux of the issue is that we did not detect the
be64toh() macro, because there is no endian.h on FreeBSD (along with
several other BSDs). So we were defaulting to our builtin version of
be64toh(). However, it appears that sys/endian.h was being picked up by
an include (likely msgpack.h) and so be64toh() was actually defined and
corrupting our definition of it.
So the answer here was to use the correct include file in our check, and
export that information in the config.h. Then we use that information
to include the right header in shada.c.
This fixes#4750.
Note: currently they are both *dumped*, but parsing them produces an error. This
is inappropriate: variables should either be skipped with error message when
dumping or should be read back properly.
It also appears that I did not have test for “has wrong variable value type”
error, so nothing got removed from errors_spec.
Unix systems must have this header but Windows does not have it at all.
Since src/nvim/os/unix_defs.h includes <unistd.h> without the guard
in order to avoid including this in the numerous places we would
need <unistd.h> on Unix we just include src/nvim/os/os.h which will pull
in <unistd.h> for us.
This header is required by POSIX for the constants (O_RDONLY, etc.)
but we were only including it on Unix systems as a side effect of
including <unistd.h>.
- ROOT_UID's comment is misleading, as it's always defined to 0.
- SEEK_{SET,END} & O_NOFOLLOW should already be defined on Unix-like
systems in <stdio.h> and <fcntl.h>, respectively. In any case,
neither of those #ifdef blocks should be in the middle of source files.
- The S_IS{LNK,DIR,...} macros should only be undefined on Windows.
Mentioned here:
https://github.com/neovim/neovim/pull/3985#issuecomment-170663426
HAVE_BE64TOH is defined in `config/config.h', which is included by
`vim.h'. Since the HAVE_BE64TOH check in `shada.c' is evaluated before
`vim.h' is included, it always evaluates to false, meaning that
be64toh() in shada.c is always used instead of the one in <endian.h>.
Moving the HAVE_BE64TOH block to after where `vim.h' is included seems
to fix the issue.
Examples:
let g:SR = [[]]
call add(g:SR[0], g:SR)
wshada
" E952: Unable to dump variable g:SR: container references itself in index 0, index 0
let g:F = {'_TYPE': v:msgpack_types.map, '_VAL': [[{'abc': 1}, function("tr")]]}
wshada
" E951: Error while dumping variable g:F, key {'abc': 1} at index 0 from special map, key '': attempt to dump function reference
" (no msgpack#string available)
" E951: Error while dumping variable g:F, key {="abc": 1} at index 0 from special map, key '': attempt to dump function reference
" (msgpack#string available)
let g:F = {'_TYPE': v:msgpack_types.map, '_VAL': [[g:SR, function("tr")]]}
wshada
" E951: Error while dumping variable g:F, key [[[[{E724@0}]]]] at index 0 from special map, index 1: attempt to dump function reference
call msgpackdump([g:SR])
" E952: Unable to dump msgpackdump() argument, index 0: container references itself in index 0, index 0
Not tested yet.
From #3473, shada.c used errno constants (e.g. ENOENT) to check the return
of os_open(), but in Windows the return from libuv functions is not -errno.
Instead use libuv error constants (e.g UV_ENOENT) for error checks.
Note: it looks like viminfo files do not store search direction intentionally.
After reading viminfo file search direction was considered to be “forward”.
Note 2: all files created on earlier Neovim version will automatically receive
“forward” direction.
Fixes#3580
