The files converted in this commit either had some random misspelling or
formatting weirdness that made them escape automated replacement, or
have a particularly "weird" licensing setup (e.g. dual-licensed.)
This also marks a bunch of "public domain" files as SPDX License "NONE".
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
We do use non-constant/literal format strings in a few places for more
or less valid reasons; put `ignored "-Wformat-nonliteral"` around those
so we can have the warning enabled for everywhere else.
Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
Analogous to Linux kernel `%pV` (but our mechanism expects 2 specifier
chars and `%pVA` is clearer anyway.)
Signed-off-by: David Lamparter <equinox@diac24.net>
With 0 currently the default value for the width specifier, it's not
possible to discern that from a %*p where 0 was passed as the length
parameter. Use -1 to allow for that.
Signed-off-by: David Lamparter <equinox@diac24.net>
This replaces `%n` with a safe, out-of-band option that simply records
the start and end offset of the output produced for each `%...`
specifier.
The old `%n` code is removed.
Signed-off-by: David Lamparter <equinox@diac24.net>
Allowing printfrr extensions to directly write to the output buffer has
a few advantages:
- there is no arbitrary length limit imposed (previously 64)
- the output doesn't need to be copied another time
- the extension can directly use bprintfrr() to put together pieces
The downside is that the theoretical length (regardless of available
buffer space) must be computed correctly.
Extended unit tests to test these paths a bit more thoroughly.
Signed-off-by: David Lamparter <equinox@diac24.net>
Make the local buffer offered to printfrr extension tokens
bigger; existing size wasn't quite enough for some of the
more elaborate struct prefix types.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
We don't use `%n` anywhere, so the only purpose it serves is enabling
exploits.
(I thought about this initially when adding printfrr, but I wasn't sure
we don't use `%n` anywhere, and thought I'll check later, and then just
forgot it...)
Signed-off-by: David Lamparter <equinox@diac24.net>
reallocarray() is walled behind stupid feature macros on various
platforms and doesn't quite gain us much in that particular use case.
Signed-off-by: David Lamparter <equinox@diac24.net>
[u]int64_t is the only type in the intX_t family that needs
special-casing for printf since the calling convention may differ
between 32-bit and 64-bit systems.
Adding the L specifier allows us to eschew the gnarly-looking PRIu64.
Signed-off-by: David Lamparter <equinox@diac24.net>
