- Add the 'handle' field to `buf_T`
- Add declare/implement functions for registering/unregistering/retrieving
buffers
- Register/unregister buffers when they are created/destroyed.
This module will be used to implement remote management of objects through the
API. Object types to be registered must have a `uint64_t` field named 'handle'.
While the mb_string2cells function accepts a length parameter, it only seems to
work properly with 0-terminated strings, since valgrind reports a conditional
jump that depends on uninitialized values(means it reads after the string
boundaries which could result in overflows or wrong results)
As discussed in #694, vim encryption uses old,
obsolete algorithms that are poorly implemented.
Since insecure cryptography is worse than no
cryptgraphy, the community voted in favor of
removing all crypto.
Various alternatives to the old crypto is
being discussed in #701.
Closes#694.
- Replace a vim_strsave/free pair with xrealloc
- Use xmallocz() in some places
- Use xrealloc() and forget about the NULL pointer case
- Remove invalid comment
- Remove unnecessary checks
- Replace a complicated xmalloc/STRCPY/free code chunk code with xrealloc()
- Replace a vim_strsave/free code chunk with xrealloc()
The map_* declarations and definitions are now created by a macro invocation
with a key type parameter. Also refactored server module to use the updated
version.
- Move `Map` structure definition to `map_defs.h`
- Use `KHASH_DECLARE` on map_defs.h to declare khash function prototypes.
- Redefine `map_foreach` into a macro
- Refactor server.c module to use the new `map_foreach` macro.
Silence -Wstrict-prototypes and static analyser warnings
Using "(void)" provides an explicit there-are-no-arguments prototype.
Using the exact type in "malloc(...sizeof)" is clearer and silences
warnings from clang's static analyzer. (John Marshall)
Instead of exposing native C types to a public API that can be consumed by other
platforms, we are now using the following translation:
int64_t -> Integer
double -> Float
bool -> Boolean
This should make the API simpler, and int64_t is enough to represent any integer
value we might need.
Range checks should be done inside the API functions, that way we can modify the
types of the actual fields/variables modified by the API without changes to the
API prototypes.
