Previously, these descriptions were only allowed on platforms where
plain 'char' is unsigned. On platforms where plain 'char' is signed,
they invoked undefined behavior or terminated the output early.
Always null-terminate the output in the buffer, even in error cases. The
wording in the manual page has been promising this since 2008. For
snprintb_m, ensure that the output is terminated with two null
characters, to gracefully handle situations in which the caller does not
check whether snprintb returned an error.
If the buffer size is zero, allow the buffer to be a null pointer,
analogous to snprintf.
Fix an out-of-bounds memory read if the bitfmt ends with a '*' directive
(since today).
In the tests, merge the helper functions for snprintb, snprintb_m, as
they were similar enough.
Fix a few 'line_max exceeded' tests, ensuring that they output a '#'
marker, and that the 'complete' tests don't.
Previously, these invoked undefined behavior, now they lead to an early
return. An example of out-of-bounds bit number is in SCZ_PCICTRL_BITS.
Bit fields that extend beyond the msb are still allowed.
Allow 'f' and 'F' to have fields that are 64 bits wide. This only makes
sense when the field starts at bit 0.
Remove the unused 'val_len', it was only needed before snprintb.c 1.20.
The manual page promises that the 'max' argument limits the length of
the generated strings, so don't generate any strings that are longer
than that limit. Mark incomplete strings with a trailing '#' to make
them easily recognizable.
The single-letter variables 't', 's', 'l' and 'c' were too hard to
decipher.
The variable 'f_len' was used for two independent purposes.
Use a narrow scope for some variables, to avoid having to keep track of
22 individual variables at the same time.
No binary change.
Remove redundant parentheses and casts.
Indent statement-like macros consistently, use separate lines for each
statement, add parentheses to macro definitions.
Remove CONSTCOND comments as lint doesn't need them anymore.
No binary change.
In the previous commit, I had accidentally only run the tests for
snprintb_m but not those for snprintb, thereby missing a newly
introduced bug that would not null-terminate the resulting strings.
Add more tests to cover similar situations in which the buffer is too
small to contain the complete output.
fully consuming the string. Adjust strtonum(3) to behave as before. Document
the order of the tests and sync the man pages (I should really autogenerate
one of the two man pages...)
the extern declaration of __libc_atomic_init() and instead using a
new one added to src/lib/libc/include/extern.h
That file is outside src/common and src/sys so is unavailable to
kernel builds, so instead make a new include file in src/common
which the kernel can read which contains the needed extern decl
for __libc_atomic_init()
This seems to fix the evbarm builds (maybe others) - but it is
all MUCH TOO UGLY to keep. Someone please make a better fix,
even if that just means reverting rev 1.5 of
src/common/lib/libc/atomic/atomic_init_cas.c
and all of the changes here (the addition to libc/include/extern.h
should be harmless to keep).
sure we free the provided string buffer if NOCOPY is not set. Fixes
a memory leak reported by M. Boerschig.
While we're at it, also change _prop_string_instantiate() to free the
provided string buffer in the not-NOCOPY case when string object allocation
fails (this was previously handled by _prop_string_instantiate()'s
callers).
PR lib/57699
- Do away with separate pool_cache for some kernel objects that have no special
requirements and use the general purpose allocator instead. On one of my
test systems this makes for a small (~1%) but repeatable reduction in system
time during builds presumably because it decreases the kernel's cache /
memory bandwidth footprint a little.
- vfs_lockf: cache a pointer to the uidinfo and put mutex in the data segment.
requirements and use the general purpose allocator instead. On one of my
test systems this makes for a small (~1%) but repeatable reduction in system
time during builds presumably because it decreases the kernel's cache /
memory bandwidth footprint a little.
- vfs_lockf: cache a pointer to the uidinfo and put mutex in the data segment.
andvar