Joerg Sonnenberger
Joerg Sonnenberger
Many of those limits were introduced to make fuzzers happy as too often people whine about excessive memory use otherwise.
Are you sure?
It's not included in the master branch, but created using `build/autogen.sh` as part of the release process.
Just like the referenced "advisory", there is no security issue here. It's a clear case of Garbage In, Garbage Out. Now we might patch it like the other instance to...
I'm quite against this change. It heavily penalizes everyone to workaround a bogus decision in certain rc scripts on NetBSD.
From experience, I find the interactions of `-fvisibility=hidden` to create more problems than it solves. As such, I'm strongly against this approach.
Don't get me wrong, I don't have a problem with the reverse approach of tagging internal functions explicitly as hidden. Let's just say that Mozilla's wrapping logic has burned me...
The only point in tagging everything would be a slight simplification for windows users. For everyone else, just tagging internal (non-static) functions with something like LA_HIDDEN is good enough. Keeping...
That said, I've been seriously considering handling it somewhat more like raw format, i.e. if it doesn't contain an explicit marker, don't auto-detect it. Only issue is that we currently...
vector resize is a straw man argument. It is optimised for dealing with trivial-move types and the standard mandates exponential grows. So yes, I am fully in favour of just...