- Check the filesize of resulting file instead of section sizes.
If there is a gap between sections, the filesize may be exceeded even
though the section total is not exceeded. Of course that doesn't
usually happen but I've experienced this during development.
Three ways to call:
getrandom(p, n, 0) Blocks at boot until full entropy.
Returns up to n bytes at p; guarantees
up to 256 bytes even if interrupted
after blocking. getrandom(0,0,0)
serves as an entropy barrier: return
only after system has full entropy.
getrandom(p, n, GRND_INSECURE) Never blocks. Guarantees up to 256
bytes even if interrupted. Equivalent
to /dev/urandom. Safe only after
successful getrandom(...,0),
getrandom(...,GRND_RANDOM), or read
from /dev/random.
getrandom(p, n, GRND_RANDOM) May block at any time. Returns up to n
bytes at p, but no guarantees about how
many -- may return as short as 1 byte.
Equivalent to /dev/random. Legacy.
Provided only for source compatibility
with Linux.
Can also use flags|GRND_NONBLOCK to fail with EWOULDBLOCK/EAGAIN
without producing any output instead of blocking.
- The combination GRND_INSECURE|GRND_NONBLOCK is the same as
GRND_INSECURE, since GRND_INSECURE never blocks anyway.
- The combinations GRND_INSECURE|GRND_RANDOM and
GRND_INSECURE|GRND_RANDOM|GRND_NONBLOCK are nonsensical and fail
with EINVAL.
As proposed on tech-userlevel, tech-crypto, tech-security, and
tech-kern, and subsequently adopted by core (minus the getentropy part
of the proposal, because other operating systems and participants in
the discussion couldn't come to an agreement about getentropy and
blocking semantics):
https://mail-index.netbsd.org/tech-userlevel/2020/05/02/msg012333.html
This was caught by a simple "typedef double Boolean" in sprite.h.
If only there were a C compiler with "strict" mode, where pointers,
numbers and booleans were separate and unassignable data types, this
copy-and-paste typo would have been caught much earlier.
When the Boolean type from sprite.h is replaced with C99's standard bool
type, the chained assignment leads to the following compile error with
GCC 5:
cond.c:404:5: error: suggest parentheses around assignment used as truth
value [-Werror=parentheses]
*quoted = qt = *condExpr == '"' ? 1 : 0;
Changing the type of qt from int to bool fixes this.
This lets the compiler decide whether to actually inline the code (which
it does). It also provides better type safety and avoids a few
underscores and parentheses in the code.
This alias was only actually used in very few places, and changing it to
unsigned char or any other type would not be possible without generating
lots of compile-time errors. Therefore there was no abstraction, only
unnecessary complexity.
Somewhere in the refactorings of the last month, the parameter types of
the Arch functions had their constness fixed, therefore the UNCONST is
no longer necessary.
When it became disabled 9 years ago, there were 15 instances of UNCONST
in the code. These have been removed in the latest cleanup sessions.
Tested with GCC 5 from NetBSD 8 and GCC 10 from pkgsrc.
I'm unhappy with the (unsigned) casts for the enum constants, but there
is no way around that since the base type of enums is int by definition,
and there is no way in C90 to explicitly specify the base type of an
enum type.
The (size_t) casts on the pointer differences are another pain point,
but for these as well, C90 does not have a ready-made solution. A
possible workaround would be an inline function ptr_diff that returns
size_t instead of ptrdiff_t, but that would make the code look even more
bloated than with the casts.
The remaining casts to (char), (int) and (time_t) look so suspicious
that it's easy enough to stumble upon them, as soon as someone finds the
time to fix these properly by adding a function ParseInt or
ParseSeconds.
- Implement pmap_growkernel(), and update kernel pmap's stats with atomics.
- Then, pmap_kenter_pa() and pmap_kremove() no longer need to allocate
memory nor take pm_lock, because they only modify L3 PTEs.
- Then, pm_lock and pp_lock can be adaptive mutexes at IPL_NONE which are
cheaper than spin mutexes.
- Take the pmap's lock in pmap_extract() if not the kernel's pmap, otherwise
pmap_extract() might see inconsistent state.
all mine)
- Use tpidr_el1 to hold curlwp and not curcpu, because curlwp is accessed
much more often by MI code. It also makes curlwp preemption safe and
allows aarch64_curlwp() to be a const function (curcpu must be volatile).
- Make ASTs operate per-LWP rather than per-CPU, otherwise sometimes LWPs
can see spurious ASTs (which doesn't cause a problem, it just means some
time may be wasted).
- Use plain stores to set/clear ASTs. Make sure ASTs are always set on the
same CPU as the target LWP, and delivered via IPI if posted from a remote
CPU so that they are resolved quickly.
- Add some cache line padding to struct cpu_info, to match x86.
- Add a memory barrier in a couple of places where ci_curlwp is set. This
is needed whenever an LWP that is resuming on the CPU could hold an
adaptive mutex. The barrier needs to drain the CPU's store buffer, so
that the update to ci_curlwp becomes globally visible before the LWP can
resume and call mutex_exit(). By my reading of the ARM docs it looks like
the instruction I used will do the right thing, but I'm not 100% sure.
- Remove memory barriers from the atomic ops. I don't understand why those
are there. Is it some architectural thing, or for a CPU bug, or just
over-caution maybe? They're not needed for correctness.
- Have unlikely conditional branches go forwards to help the static branch
predictor.
This change fixes a bug that extra delay() is called only once even if
atomic_cas_uint() isn't failed or delay() isn't called when atomic_cas_uint()
failed.
The reason of this bug was that I simply converted FreeBSD' atomic_cmpset_int()
to atomic_cas_uint(). The return value's semantics is different.
else sys.mk will attempt to write it to the source tree,
which may be r/o and fail.
XXX may cause updates builds to fail because a file listed
in .depend won't exist anymore.
Just in case the given str is not really a string.
The POSIX 2018 documentation on strndup does not specify as clearly as
possible whether s has to be a string or whether raw memory is
acceptable as well. It only indirectly calls the s parameter of strndup
a string.
This avoids unnecessary string allocations, especially for long lists.
There is no unit test to cover this code. Since this is an obscure,
undocumented part of make, I wasn't able to come up with a unit test.
Therefore I resorted to write a separate testing program to verify the
expected results.
$ cat <<'EOF' >dir_test.c
#include <stdio.h>
#include "make.h"
#include "dir.h"
int main(int argc, char **argv)
{
int i;
Lst lst;
char *flags;
lst = Lst_Init(FALSE);
for (i = 1; i < argc; i++)
Dir_AddDir(lst, argv[i]);
flags = Dir_MakeFlags("-I", lst);
printf("%s\n", flags);
free(flags);
return 0;
}
EOF
# Needs some trivial patches to Makefile and main.c
$ make PROG=dir_test EXTRA_SRCS=dir_test.c EXTRA_CPPFLAGS=-DNO_MAIN \
COPTS.main.c=-Wno-unused-function NOMAN=1
$ ./dir_test a b c
$ mkdir a b c
$ ./dir_test a b c
-Ia -Ib -Ic
$ rmdir a b c
