- The data member of String's can now be passed directly to functions
expecting C strings, as we now guarantee that they are NUL-terminated.
This obviates the need to use xstrndup and free, simplifying code and
enhancing performance.
- Use xmemdupz instead of xstrndup for converting String's into C strings.
It's faster because it doesn't calculate strlen(string.data) (which is
unnecesary as that information is already provided in string.size anyway).
- Use cstr_to_string to convert from C strings to String, it is both shorter
and faster than the usual strlen/xstrndup combo, which calls strlen twice.
cstr_to_string internally calls strlen and then xmemdupz.
I believe we can now mostly assume that all encountered String's data
members are safe to pass into functions that accept C strings. That should
simplify interop with C string code.
It's a 1-byte loss of memory but it allows us to skip copying and
NULL-terminating strings when interacting with vim functions that accept C
strings. This lowers the pressure on the allocator and saves lines of code
(no more dup/free pairs).
mb_string2cells was always called like mb_string2cells(..., -1) so that was
the only codepath that was tested. @tarruda was the first to try to input an
actual length, after which valgrind detected that funny business was going
on.
It's not even possible to do the right thing with the current text codec
infrastructure: they all assume to be working with C strings. Meaning that
if there is no NUL-terminator, they will happily keep on reading past the
end of Pascal strings. Ergo, passing the length parameter is moot. The
condition in the for-loop was wrong as well (but that's no longer relevant).
Also change the return value to size_t, by analogy with strlen.
ref:
677d30d796
Most of these functions don't modify their strings, let's make the contract
a bit clearer. In some cases I've tried to get rid of C89-style variable
declarations at the start of functions, now that I was there.
Problem: Searching for "a" does not match accented "a" with new regexp
engine, does match with old engine. (David Bürgin)
"ca" does not match "ca" with accented "a" with either engine.
Solution: Change the old engine, check for following composing character
also for single-byte patterns.
https://code.google.com/p/vim/source/detail?r=60cdaa05a6ad31cef55eb6b3dc1f57ecac6fcf79
Modify gendeclarations.lua to check if the generated non-static declaration
header changed before rewriting it with a new version. This is to prevent
unnecessary rebuilds of modules that depend on modules that had private changes.
- The 'stripdecls.py' script replaces declarations in all headers by includes to
generated headers.
`ag '#\s*if(?!ndef NEOVIM_).*((?!#\s*endif).*\n)*#ifdef INCLUDE_GENERATED'`
was used for this.
- Add and integrate gendeclarations.lua into the build system to generate the
required includes.
- Add -Wno-unused-function
- Made a bunch of old-style definitions ANSI
This adds a requirement: all type and structure definitions must be present
before INCLUDE_GENERATED_DECLARATIONS-protected include.
Warning: mch_expandpath (path.h.generated.h) was moved manually. So far it is
the only exception.
