enh-google
enh-google
Fixes the use-after-free of `pd` caused by leaving the signal handlers that call pcap_breakloop() active after freeing the `struct pcap_t`. This also fixes the leak of `device`. Caught by gwp-asan...
see https://issuetracker.google.com/211696118 for the original bug report. the code's moved about and is at https://github.com/Maratyszcza/pthreadpool/blob/a134dd5d4cee80cce15db81a72e7f929d71dd413/src/memory.c#L27 now, but the bug's still there. probably wants to be something like this instead: ```...
the _first_ thing on the page should probably be the deprecation notice, and then _just_ a link to the migration samples, with the rest only of historical interest now?
going through help text, i noticed that iconv's `-s` isn't documented because it's always on, which seems like an unfortunate default. more than that, the `-c` behavior isn't right either:...
example from https://android-review.googlesource.com/c/platform/external/toybox/+/2555514?tab=comments --- ``` if (echo '#ifdef __amd64'; echo IS_64BIT_ARCH; echo '#endif') | \ # ERROR ON LINE BELOW (CCOPTS= $CC_FOR_BUILD -E - 2>/dev/null) | \ grep IS_64BIT_ARCH >/dev/null...
we had a request for --rsyncable from the cuttlefish (https://source.android.com/docs/setup/create/cuttlefish) folks. i was going to send a patch for this (at least for the zlib-backed variant) but it turns out...
we (via bionic) already test that `__riscv_hwprobe()` claims fast misaligned accesses, but https://github.com/llvm/llvm-project/issues/88029 is a case where hardware [correctly] claims fast misaligned accesses ... but mutters "scalar" under its breath...
There are some `String` intrinsics to implement, most importantly `StringCompareTo` and `StringEquals`. The question is whether we want to bother with scalar implementations or implement them with the "V" extension...
see here for an up to date list of unimplemented intrinsics: https://cs.android.com/android/platform/superproject/main/+/main:art/compiler/optimizing/code_generator_riscv64.h;l=58?q=UNIMPLEMENTED_INTRINSIC_LIST_RISCV64%20file:risc (though it's worth comparing with arm64/x86-64 too, since they don't implement all of them either!)
init can ask for more aslr bits when we have newer kernels: https://android-review.git.corp.google.com/c/platform/system/core/+/2251618/1..2/init/security.cpp#b120 TODO: find out what kernel version improves this; ToT still only has 24 in arch/riscv/Kconfig --- https://github.com/torvalds/linux/blob/master/arch/riscv/Kconfig#L150...