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
It is not logical that on UNIX permissions can prevent even writing temporary
file, while on other OS it will first write temporary file and then fail during
rename.
It was the behaviour exhibited by Vim, but it got unintentionally removed. There
is a difference though: Vim runs fchown *before* populating the file, I run it
just before renaming.
This problem made test64 to crash. Description of the bug: when removing entry
from history when removed entry is not the last one it puts one element to
free_entries list, but ignores free entries starting from last_free_element.
Possible solutions:
1. First working: simply populate free_entries list with entries which are still
free, starting from last_free_element.
2. Better (wastes less CPU): after free_entries list size goes to zero (which is
the initial value) continue using last_free_element.
3. Even better (less memory): note that element from the list is *only* removed
before adding another one. So replace free_entries array with one item.
Also renamed last_free_element to last_free_entry: in any case most of the lines
which mention it were altered.
