i have seen true evil. yes.
mozilla firefox has a custom allocator that redefines/macros a bunch of malloc/free calls. it does this to intercept them, calling the real (system) allocator sparingly in large chunks, and its own for small allocations. useful for optimising lots of small allocations.
the code doesn't match obsd. llvm 19 was ok, 20+ is stricter. re-trying librewolf 149 build on obsd current, wiith llvm 19... otherwise i'll just build with --disable-jemalloc (i want to avoid that)
i *will* have librewolf 149 compiling, TONIGHT, on openbsd -CURRENT
if building with llvm 19 still dosen't work, i'm going to gut mozilla's allocator myself, fixing all the declarations by hand.
using the system allocator directly (no intercept functions) is possible using --disable-jemalloc in ./configure, when building mozilla code. but that means using openbsd's... slow allocator, for every allocation. and that would make the javascript engine slow as molasses.
mozilla firefox is a sin.
fuck u mozilla
--- memory/build/mozjemalloc.cpp.orig
+++ memory/build/mozjemalloc.cpp
@@ -5257,7 +5257,7 @@ static void replace_malloc_init_funcs(malloc_table_t* table) {
#endif
#define NOTHROW_MALLOC_DECL(...) \
- MOZ_MEMORY_API MACRO_CALL(GENERIC_MALLOC_DECL, (noexcept(true), __VA_ARGS__))
+ MOZ_MEMORY_API MACRO_CALL(GENERIC_MALLOC_DECL, (, __VA_ARGS__))
u will not defeat me mozilla
Leah Rowe ist kein Roweboter