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.
Cutting off in the middle may leave the terminal in a bad state, breaking
further output. But we don't know what a given ANSI sequence does, e.g.
ANSI_NORMAL should not be skipped. But it is also nice to keep various
sequences intact, so that if we had part of the string in blue, and we cut out
the beginning of the blue part, we still want to keep the remainder in color.
So let's just pass them through, stripping out the characters that take up
actual space.
Also, use memcpy_safe as we may end up copying zero bytes when ellipsizing at
the start/end of a string.
Fixes: #24502
This also fixes an ugliness where we would ellipsize string with ANSI
sequences too much, leading to output that was narrower on screen than the
requested length:
Starting AAAAAAAAAAAAAAAAAAAAA.service
Starting BBBBBBBBBBBBBBBBBBBBB.service
Starting LONG…ER.service
Co-authored-by: Jan Janssen <medhefgo@web.de>
While we are at it, replace the sloppy use of filename_is_valid() by the
less sloppy filename_part_is_valid() (as added by the preceeding
commit), since we don#t want to be too restrictive here. (After all,
version strings invalid as standalone filenames might be valid as part
of filenames, and hence we should allow them).
When closing the FILE handle attached to a memstream, it may attempt to
do a realloc() that may fail during OOM situations, in which case we are
left with the buffer pointer pointing to NULL and buffer size > 0. For
example:
```
#include <errno.h>
#include <stdio.h>
#include <stdlib.h>
void *realloc(void *ptr, size_t size) {
return NULL;
}
int main(int argc, char *argv[])
{
FILE *f;
char *buf;
size_t sz = 0;
f = open_memstream(&buf, &sz);
if (!f)
return -ENOMEM;
fputs("Hello", f);
fflush(f);
printf("buf: 0x%lx, sz: %lu, errno: %d\n",
(unsigned long) buf, sz, errno);
fclose(f);
printf("buf: 0x%lx, sz: %lu, errno: %d\n",
(unsigned long) buf, sz, errno);
return 0;
}
```
```
$ gcc -o main main.c
$ ./main
buf: 0x74d4a0, sz: 5, errno: 0
buf: 0x0, sz: 5, errno: 0
```
This might do unexpected things if the underlying code expects a valid
pointer to the memstream buffer after closing the handle.
Found by Nallocfuzz.
This is the function version of STARTSWITH_SET(). We also move
STARTSWITH_SET() to string-util.h as it fits more there than in
strv.h and reimplement it using startswith_strv().
Daan De Meyer
Yu Watanabe
Mike Yuan
Alberto Planas
Zbigniew Jędrzejewski-Szmek
Lennart Poettering
Rose
Joerg Behrmann
Frantisek Sumsal
Luca Boccassi
zhmylove
David Tardon