| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
We use _printf_ for these functions, so there shouldn't
be a warning in the first place.
|
| |
|
|
|
|
| |
We want to include stdio-util.h in log.h in a future commit. To avoid
circular includes, we need to drop the memory-util.h include from
stdio-util.h
|
| |
|
|
|
|
|
|
| |
This allows passing pre-allocated buffers via compound initializers
to snprint_ok(). If snprintf_ok() is a macro, the compound initializer
block will be scoped to the macro block, if snprint_ok() is a function,
the compound initializer block will be scoped to the block from which
snprintf_ok() is called.
|
| |
|
|
| |
xsprintf(buf, "…: %m") would fail, now it works.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
as per docs snprintf() can fail in which case it returns -1. The
snprintf_ok() macro so far unconditionally cast the return value of
snprintf() to size_t, which would turn -1 to (size_t) INT_MAX,
presumably, at least on 2 complements system.
Let's be more careful with types here, and first check if return value
is positive, before casting to size_t.
Also, while we are at it, let's return the input buffer as return value
or NULL instead of 1 or 0. It's marginally more useful, but more
importantly, is more inline with most of our other codebase that
typically doesn't use booleans to signal success.
All uses of snprintf_ok() don't care for the type of the return, hence
this change does not propagate anywhere else.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
|
| | |
|
| |
|
|
| |
Just some source rearranging.
|
| |
|
|
| |
This gets around https://github.com/google/sanitizers/issues/992.
|
| |
|
|
|
|
|
|
|
|
|
| |
These lines are generally out-of-date, incomplete and unnecessary. With
SPDX and git repository much more accurate and fine grained information
about licensing and authorship is available, hence let's drop the
per-file copyright notice. Of course, removing copyright lines of others
is problematic, hence this commit only removes my own lines and leaves
all others untouched. It might be nicer if sooner or later those could
go away too, making git the only and accurate source of authorship
information.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This part of the copyright blurb stems from the GPL use recommendations:
https://www.gnu.org/licenses/gpl-howto.en.html
The concept appears to originate in times where version control was per
file, instead of per tree, and was a way to glue the files together.
Ultimately, we nowadays don't live in that world anymore, and this
information is entirely useless anyway, as people are very welcome to
copy these files into any projects they like, and they shouldn't have to
change bits that are part of our copyright header for that.
hence, let's just get rid of this old cruft, and shorten our codebase a
bit.
|
| |
|
|
|
|
|
|
|
|
| |
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc-8 throws an error if it knows snprintf might truncate output and the
return value is ignored:
../src/udev/udev-builtin-net_id.c: In function 'dev_pci_slot':
../src/udev/udev-builtin-net_id.c:297:47: error: '%s' directive output may be truncated writing up to 255 bytes into a region of size between 0 and 4095 [-Werror=format-truncation=]
snprintf(str, sizeof str, "%s/%s/address", slots, dent->d_name);
^~
../src/udev/udev-builtin-net_id.c:297:17: note: 'snprintf' output between 10 and 4360 bytes into a destination of size 4096
snprintf(str, sizeof str, "%s/%s/address", slots, dent->d_name);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: some warnings being treated as errors
Let's check all return values. This actually makes the code better, because there's
no point in trying to open a file when the name has been truncated, etc.
|
| |
|
|
|
| |
This follows what the kernel is doing, c.f.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fd54ace4721fc5ce2bb5aef6318fcf17f421460.
|
| | |
|
| |
|
|
|
| |
This should be handled fine now by .dir-locals.el, so need to carry that
stuff in every file.
|
| |
|
