reverting broad cosmetic/style change because:
- increases merge-conflicts
- increases overhead of merging upstream Vim patches
- reasons for change are ambiguous, so default to no change
I've checked all uses of ga_concat in the codebase:
- ex_cmds2.c
- ex_getln.c
- eval.c
- message.c
- regexp-nfa.c
- term.c
- spell.c
None of them concats the garray with itself. This makes it safe to use the
faster memcpy() instead of memmove(). This change was also documented.
Less useless strlen(), stpcpy() is a more natural fit for this task.
ga_concat_strings() still has too much strlen() but that would be ugly to
remove for a function that's not used very often (just once in the current
codebase).
- xrealloc will call xmalloc if the input pointer is NULL, no need to check
twice.
- use the early-quit idiom to decrease the indentation, which enhances
readability.
- xmallocz() is not static anymore. There are many use cases for this function
in the codebase and we should start using it.
- Simpler types in ga_concat_strings()
By simpler cases I mean cases where the OOM error is not expected to be handled
by the caller of the function that calls `alloc`, `lalloc`, `xrealloc`,
`xmalloc`, `alloc_clear`, and `lalloc_clear`.
These are the functions that:
- Do not return an allocated buffer
- Have OOM as the only error condition
I took note of the functions that expect the caller to handle the OOM error and
will go through them to check all the callers that may be handling OOM error in
future commits.
I'm ignoring eval.c and ex_.c in this series of commits. eval.c will soon be
obsolete and I will deal with ex_.c in later PRs.
