| Age | Commit message (Collapse) | Author | Files |
|---|
|
|
|
Problem: C-type names are marked as translatable
Solution: Use them as-is, do not translate them
(Eisuke Kawashima)
closes: vim/vim#19861
https://github.com/vim/vim/commit/a5b6c2d6e928b1f7a1c3e20baef717d31c2e8d6a
Co-authored-by: Eisuke Kawashima <e-kwsm@users.noreply.github.com>
|
|
Problem: Compiler warning in strings.c
(Timothy Rice, after v9.2.0031)
Solution: Return early when str_m is zero
(Hirohito Higashi)
fixes: vim/vim#19795
closes: vim/vim#19800
https://github.com/vim/vim/commit/347e8c1e7d17c0c6aa044789def8dfaf07475a39
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
|
|
fix(build): glibc 2.43 happened
|
|
using the GNU compiler we just get a bunch of const warnings we can fix.
clang, however, gets really upset that the standard library suddenly
starts using a lot of c11 features, despite us being in -std=gnu99 mode.
Basically, _GNU_SOURCE which we set is taken as a _carte blanche_ by the
glibc headers to do whatever they please, and thus we must inform clang
that everything is still OK.
|
|
(#38159)
Problem: byteidx_common() and f_utf16idx() are calling ptr2len() twice
per iteration, instead of reusing the already computed clen.
Solution: Reuse clen for pointer advancement in both functions
(Yasuhiro Matsumoto).
closes: vim/vim#19573
https://github.com/vim/vim/commit/499e93d09a9d687baafaa922660fc19dd30ffa45
N/A patches:
vim-patch:9.2.0109: VIM_BACKTICK is always defined except for tiny builds
Co-authored-by: Yasuhiro Matsumoto <mattn.jp@gmail.com>
|
|
Problem: Compile warning in strings.c
Solution: Use const qualifier (John Marriott).
closes: vim/vim#19387
https://github.com/vim/vim/commit/388654af27a6e422172d6ee6c40b061f5dd6dfa0
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
in printf() (#36919)
Problem: crash with invalid positional argument 0 in printf()
Solution: Reject positional arguments <= 0.
closes: vim/vim#18898
https://github.com/vim/vim/commit/98a0cbf05bd45fa6c4ede7b791fd21760bc587c8
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: string handling in strings.c can be improved
Solution: Refactor strings.c and remove calls to STRLEN()
(John Marriott)
This change does:
- In vim_strsave_shellescape() a small cosmetic change.
- In string_count() move the call to STRLEN() outside the while loop.
- In blob_from_string() refactor to remove call to STRLEN().
- In string_from_blob() call vim_strnsave() instead of vim_strsave().
- In vim_snprintf_safelen() call vim_vsnprintf_typval() directly instead
of vim_vsnprintf() which then calls vim_vsnprintf_typval().
- In copy_first_char_to_tv() change to return -1 on failure or the length
of resulting v_string. Change string_filter_map() and string_reduce() to
use the return value of copy_first_char_to_tv().
closes: vim/vim#18617
https://github.com/vim/vim/commit/110656ba607d22bbd6b1b25f0c05a1f7bad205c0
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
Problem: too many strlen() calls in buffer.c
Solution: refactor buffer.c and remove strlen() calls
(John Marriott)
closes: vim/vim#17063
https://github.com/vim/vim/commit/ec032de6465f159bd57c22d464e0f4815f3aefc7
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
These are not needed after #35129 but making uncrustify still play nice
with them was a bit tricky.
Unfortunately `uncrustify --update-config-with-doc` breaks strings
with backslashes. This issue has been reported upstream,
and in the meanwhile auto-update on every single run has been disabled.
|
|
Problem: max allowed string width too small
Solution: increased MAX_ALLOWED_STRING_WIDTH from 6400 to 1MiB
(Hirohito Higashi)
closes: vim/vim#17138
https://github.com/vim/vim/commit/06fdfa11c565599ac13ad5c077d1dabbbfde03ac
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
(#32792)
Problem: Unnecessary use of vim_tolower() in vim_strnicmp_asc().
Solution: Use TOLOWER_ASC() instead (zeertzjq).
It was passing *s1 and *s2 to vim_tolower(). When char is signed, which
is the case on most platforms, c < 0x80 is always true, so it already
behaves the same as TOLOWER_ASC().
closes: vim/vim#16826
https://github.com/vim/vim/commit/b7dc5d3b6169efc8aa0b9d86476072877e74bc2c
Use this function for hashy case-insensitive lookup, as it's ASCII-only.
Note that this function doesn't cast TOLOWER_ASC() argument to uint8_t,
so it'll treat a UTF-8 byte as smaller than NUL. It doesn't matter, as
one of the strings being compared is ASCII-only, and its behavior still
leads to consistent ordering.
|
|
A binary format spec always expects a corresponding unsigned long long
value. However, that explicit handling didn't get included when porting
the code from Vim, so binary format spec was falling through to the
"unsigned" and "length_modifier = NUL" portion of the code:
} else {
// unsigned
switch (length_modifier) {
case NUL:
uarg = (tvs
? (unsigned)tv_nr(tvs, &arg_idx)
: (skip_to_arg(ap_types, ap_start, &ap, &arg_idx,
&arg_cur, fmt),
va_arg(ap, unsigned)));
break;
This incorrectly read an "unsigned" value from an "unsigned long long"
variable, which would produce incorrect results on certain platforms.
|
|
Problem: vim_strnchr() is strange and unnecessary (after v9.1.1009)
Solution: Remove vim_strnchr() and use memchr() instead. Also remove a
comment referencing an #if that is no longer present.
vim_strnchr() is strange in several ways:
- It's named like vim_strchr(), but unlike vim_strchr() it doesn't
support finding a multibyte char.
- Its logic is similar to vim_strbyte(), but unlike vim_strbyte() it
uses char instead of char_u.
- It takes a pointer as its size argument, which isn't convenient for
all its callers.
- It allows embedded NULs, unlike other "strn*" functions which stop
when encountering a NUL byte.
In comparison, memchr() also allows embedded NULs, and it converts bytes
in the string to (unsigned char).
closes: vim/vim#16579
https://github.com/vim/vim/commit/34e1e8de91ff4a8922d454e3147ea425784aa0a0
|
|
Result of `make iwyu` (after some "fixups").
|
|
Problem:
Casting long to int introduces risk of overflow.
Solution:
Work with all int64_t (long) rather than casting back and forth.
|
|
Problem:
Linematch used to use strchr to navigate a string, however strchr does
not supoprt embedded NULs.
Solution:
Use `mmfile_t` instead of `char *` in linematch and introduce `strnchr()`.
Also remove heap allocations from `matching_char_iwhite()`
Fixes: #30505
|
|
(#29907)
Problem: E1510 may happen when formatting a message
(after 9.1.0181).
Solution: Only give E1510 when using typval. (zeertzjq)
closes: vim/vim#15391
https://github.com/vim/vim/commit/0dff31576a340b74cec81517912923c38cb28450
|
|
Also add test for using printf() and id() with a Blob.
|
|
|
|
|
|
Problem: No test for escaping '<' with shellescape()
Solution: Add a test. Use memcpy() in code to make it easier to
understand. Fix a typo (zeertzjq).
closes: vim/vim#14876
https://github.com/vim/vim/commit/88c8c547d5fc380e5685c2b01ec564ccdf9b259a
|
|
Problem: MS-Windows: Compiler warnings
Solution: Resolve size_t to int warnings
closes: vim/vim#14874
A couple of warnings in ex_docmd.c have been resolved by modifying their
function argument types, followed by some changes in various function
call sites. This also allowed removal of some casts to cope with
size_t/int conversion.
https://github.com/vim/vim/commit/51024bbc1a9e298b1fb8f2e465fccb5db409551e
Co-authored-by: Mike Williams <mrmrdubya@gmail.com>
|
|
Problem: too many strlen() calls in the regexp engine
Solution: refactor code to retrieve strlen differently, make use
of bsearch() for getting the character class
(John Marriott)
closes: vim/vim#14648
https://github.com/vim/vim/commit/82792db6315f7c7b0e299cdde1566f2932a463f8
Cherry-pick keyvalue_T and its comparison functions from patch 9.1.0256.
vim-patch:9.1.0410: warning about uninitialized variable
vim-patch:9.1.0412: typo in regexp_bt.c in DEBUG code
Co-authored-by: John Marriott <basilisk@internode.on.net>
|
|
|
|
Problem: no overflow check for string formatting
Solution: Check message formatting function for overflow.
(Chris van Willegen)
closes: vim/vim#13799
https://github.com/vim/vim/commit/c35fc03dbd47582b256776fb11f11d8ceb24f8f0
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
|
|
Current uses of vim_strup() calls memcpy()/strcpy() before calling vim_strup().
This results in 2 * strlen(string) operations.
We can trivially convert to lowercase while copying the string instead.
|
|
Before, we needed to always pack an entire msgpack_rpc Object to
a continous memory buffer before sending it out to a channel.
But this is generally wasteful. it is better to just flush
whatever is in the buffer and then continue packing to a new buffer.
This is also done for the UI event packer where there are some extra logic
to "finish" of an existing batch of nevents/ncalls. This doesn't really
stop us from flushing the buffer, just that we need to update the state
machine accordingly so the next call to prepare_call() always will
start with a new event (even though the buffer might contain overflow
data from a large event).
|
|
|
|
Problem: Double xmalloc usage led to excess memory allocations.
Solution: Switch to xrealloc to adjust memory as needed, minimizing allocations.
|
|
Remove `export` pramgas from defs headers as it causes IWYU to believe
that the definitions from the defs headers comes from main header, which
is not what we really want.
|
|
|
|
|
|
Specifically, specify that each initialization should be done on a
separate line.
|
|
FUNC_ATTR_* should only be used in .c files with generated headers.
Defining FUNC_ATTR_* as empty in headers causes misuses of them to be
silently ignored. Instead don't define them by default, and only define
them as empty after a .c file has included its generated header.
|
|
|
|
|
|
|
|
This requires removing the "Inner expression should be aligned" rule
from clint as it prevents essentially any formatting regarding ternary
operators.
|
|
- reduce variable scope
- prefer initialization over declaration and assignment
|
|
- reduce variable scope
- prefer initialization over declaration and assignment
- use bool to represent boolean values
|
|
We already have an extensive suite of static analysis tools we use,
which causes a fair bit of redundancy as we get duplicate warnings. PVS
is also prone to give false warnings which creates a lot of work to
identify and disable.
|
|
When the given length is exactly the number of bytes to copy, xmemdupz()
makes the intention clearer.
|
|
Problem: trim(): hard to use default mask (partly revert v9.0.2040)
Solution: use default mask when it is empty
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
Currently, an empty 'mask' will make 'trim()' call return 'text' value
that is passed in unmodified. It is unlikely that someone is using it,
so the chances of scripts being broken by this change are low.
Also, this reverts commit 9.0.2040 (which uses v:none for the default
and requires to use an empty string instead).
closes: vim/vim#13358
https://github.com/vim/vim/commit/8079917447e7436dccc2e4cd4a4a56ae0a4712f2
vim-patch:9.0.2040: trim(): hard to use default mask
Problem: trim(): hard to use default mask
Solution: Use default 'mask' when it is v:none
The default 'mask' value is pretty complex, as it includes many
characters. Yet, if one needs to specify the trimming direction, the
third argument, 'trim()' currently requires the 'mask' value to be
provided explicitly.
'v:none' is already used to mean "use the default argument value" in
user defined functions. See |none-function_argument| in help.
closes: vim/vim#13363
https://github.com/vim/vim/commit/6e6386716f9494ae86027c6d34f657fd03dfec42
Co-authored-by: Illia Bobyr <illia.bobyr@gmail.com>
|
|
Problem: Some unused code in move.c and string.c
Solution: Remove it
closes: vim/vim#13288
https://github.com/vim/vim/commit/580c1fcb4ad85360cd3a361c3c8e37b534153d60
Co-authored-by: dundargoc <gocdundar@gmail.com>
|
|
Problem: strange error number
Solution: change error number,
add doc tag for E1507
closes: vim/vim#13270
https://github.com/vim/vim/commit/ea746f9e862092aef3d4e95c64d116759b9fabe0
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
|
|
|
|
Problem: Vim9: error codes spread out
Solution: group them together and reserve 100
more for future use
Reserve 100 error codes for future enhancements to the Vim9 class
support
closes: vim/vim#13207
https://github.com/vim/vim/commit/413f83990f15d5d59d27ab741670f527a7a3feb8
Co-authored-by: Yegappan Lakshmanan <yegappan@yahoo.com>
|
|
Problem: Wrong order of arguments for error messages
Solution: Reverse order or arguments for e_aptypes_is_null_nr_str
closes: vim/vim#13051
https://github.com/vim/vim/commit/1bd2cb11694690a77e4141bce2e34d9dfb882f1c
Co-authored-by: Christ van Willegen <cvwillegen@gmail.com>
|
