Split out of #41543.
These don't make too much sense on their own, but they also don't really
hurt. They are preparation for #41543, but in order to make things
either to review I split these four commits out, since they are not
directly part of what the PR shall achieve
This simply mirrors the same overflow check we already have in
strrepa(), in case someone passed us a sufficiently long string.
strrep() is currently used only in tests, so this is just hardening.
The updated parsing_hacks.h file uncovered a bunch of extra
things that the check-pointer-deref coccinelle script flags.
This commit fixes them to make the tree check-pointer-deref clean.
Add the needed assert changes to make the code clean
for the new check-pointer-deref script.
Note that for `_cmp()` functions its a bit of a question
if we want `assert()` or `POINTER_MAY_BE_NULL()` here. The
former is more correct but it adds a (small) runtime hit. If
we use POINTER_MAY_BE_NULL() it is compiled out but strictly
speaking it is wrong (so at least we would need a comment).
string_has_ansi_sequence() currently does this to look for ESC input:
t = memchr(s, 0x1B, ...)
So each iteration re-searches from the original start pointer. But if we
find an ESC byte that does *not* start a valid ANSI sequence (like "\x1B
", or an ESC at the end of the string), then ansi_sequence_length()
returns 0, and if that ESC is still in the search window, we will just
spin consuming 100% CPU forever.
Fix this by always advancing past rejected ESC bytes.
Since 6eabe9f2ff we generate sequences
with ":", hence we better also know how to strip them.
(Without this patch we'd strip simple ANSI colors, but not RGB ones that
use ":" syntax).
(While we are at it, also drop a duplicate "0" in the list of valid
chars)
Latest glibc uses _Generic to have strstr() and other functions return
const char* or char* based on whether the input is a const char* or a
char*. This causes build failures as we previously always expected a char*.
Let's fix the compilation failures and add our own macros similar to glibc's
to have string functions that return a mutable or const pointer depending on
the input.
As a wrapper for `find_line_startswith`, `find_line_after` search for
the exact line and return the pointer for the next line, or NULL if
missing.
`find_line` with search for the exact line and return the pointer to the
beginning of the line.
Signed-off-by: Alberto Planas <aplanas@suse.com>
Now that the necessary functions from log.h have been moved to macro.h,
we can stop including log.h in macro.h. This requires modifying source
files all over the tree to include log.h instead.
Admittedly, some of our glyphs _are_ special, e.g. "O=" for SPECIAL_GLYPH_TOUCH ;)
But we don't need this in the name. The very long names make some invocations
very wordy, e.g. special_glyph(SPECIAL_GLYPH_SLIGHTLY_UNHAPPY_SMILEY).
Also, I want to add GLYPH_SPACE, which is not special at all.
in strv_new() we have STRV_IGNORE for skipping over an argument in the
argument list. Let's add the same to strextend_with_separator():
strextend_with_separator(&x, "foo", POINTER_MAX, "bar");
will result in "foobar" being appended to "x". (POINTER_MAX Which is
different from NULL, which terminates the argument list).
This is useful for ternary op situations.
(We should probably get rid of STRV_IGNORE and just use POINTER_MAX
everywhere directly, but that's for another time.)
The functions are very similar, let's make them the same. If the first
argument to strextend() is NULL instead of extending a string we'll
allocate a fresh one and return that.
It's a bit ugly to have both strdup_to() and strdup_to_full(). I initially
started with one variant, but then in some functions we want the additional
info, while in many other places, having 1 instead of 0 causes the return
value of whole chains of functions to be changed. It *probably* wouldn't cause
any difference, but there is at least of bunch of tests that would need to be
updated, so in the end it seems to have the two variants.
The output param is first to match free_and_strdup() and other similar
functions.
This is useful for two reasons:
1. it addresses a potential overflow in a graceful way
2. Gives callers the ability to just pass SIZE_MAX for a NOP
Prompted by: #31341
This commits adds version_is_valid_versionspec and uses it in
analyze-compare-version.c.
version_is_valid_versionspec differs from version_is_valid in that it acepts
empty strings and since valid characters in a version spec version are all
ASCII letters and digits as well as "-.~^", but ",_+" allowed by
version_is_valid are not.
Also give a more specific warning message on invalid characters.