Although GCC now detects possibly unintentional fall through, there
rules around which the comments are detected are rather strict. In
cases where a comment isn't detected, upstream [recommends] using their
fallthrough attribute.
[recommends]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77817#c11
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.
