And sadly that was one that I broke trying to refactor together all our C++ autoconf tests. Silver lining, I added a test for it so if I break it again we should notice earlier.
"some community effort" is a huge understatement. Let me rephrase that for you: "Possibly the largest ever single contribution to Valgrind".
Initial work on this was started by an engineer at Intel. She was based in St Petersburg so that work stalled in 2022. Here is the bugzilla item https://bugs.kde.org/show_bug.cgi?id=383010. The other big issue is that we don't have enough people working on Valgrind that are experts with the virtual CPU. There are a couple of guys working on s390 and a little bit of work is being done reusing amd64 sse4 support on x86. I dabble a little bit on arm64,
If there are any AVX512 experts that would like to help with this it would be most welcome.
Please give it a try in configurations that are important for you and
report any problems you have, either on this mailing list, or
(preferably) via our bug tracker at
https://bugs.kde.org/enter_bug.cgi?product=valgrind
The final 3.27.0 release is scheduled for Mon Apr 20.
See my other reply for contents. Changed since RC0:
Copyright notices, Linux fsconfig syscall fix, s390 instruction selection bug, macOS build failure from distribution tarballs, a few more opcodes handled on x86.
We still use KDE's bugzilla. One of the reasons that Vagrind was initially developed was to help with KDE back when many developers didn't really understand how to use new and delete.
These days sourceware.org hosts the Valgrind git repo, buildbot CI and web site. We could also use their bugzilla. There isn't much point migrating as long as KDE can put up with us.
There was someone at Intel working on AVX512 support in Valgrind. She is/was based in St Petersburg. Intel shuttered their Russian operations when Putin invaded Ukraine and that project stalled.
If anyone has the time and knowledge to help with AVX512 support then it would be most welcome. Fair warning, even with the initial work already done this is still a huge project.
The problem is that there are many many people that are falling over themselves to believe bogus claims about false positives.
Outside of Valgrind bugzilla bug reports these claims almost never stand up to close scrutiny. Not that the people making the claims ever perform any scrutiny. It's usually "my application doesn't crash so it must be a false positive" or "I'm sure that I initialised that variable" or "it's not really a leak, the OS will reclaim the memory".
I'm working on Valgrind on macOS, integrating Louis Brunner's work and trying to add a few more fixes. In 2025 support for macOS Intel 10.14, 10.15 11 and 12 was added. Intel macOS 13 is a bit harder of a nut to crack. And I have lots of issues with ARM, particularly building and testing on anything older that macOS 15.
Swift name-mangling will be an issue. Valgrind's name demangler comes from GNU binutils libiberty which does not support Swift AFAIK.
In my experience that is usually the result of years and years of accumulation of shit code. The results is thousands of leaks. That makes detection of incremental leaks much more difficult. If you start with clean code and use ASAN or Valgrind then leak detection is not difficult.
Your library has many issues. Some should be easy to fix. You missed many allocation/deallocation functions (3 from ISO C, 1 from POSIX and 4 non-standard ones).
Others will be difficult or impossible for you to address. Your use of --wrap will not work with exes that link to static libc. macOS ld does not support --wrap. You will need to use another mechanism if you want to support macOS. I assume not supporting Windows is intentional.
The other big issue is with custom memory pools. That is always a difficult problem. Valgrind and the sanitizers require user instrumentation. Your leak detection will work with memory pools that just subdivide memory allocated with malloc etc. It won't work for memory pools that work like malloc itself and use brk/sbrk/mmap.
> Let’s make C testing suck less in 2025.
Didn't Bjarne Stroustrup do that already back in 1985?
Are you trying to explain to me how Valgrind works? If you do know more than me then please join us and become a Valgrind developer.
Mostly it wraps system calls and library calls. Wrapping means that it does some checking or recording before and maybe after the call. Very occasionally it needs to modify the arguments to the call. The rest of the time it passes the arguments on to the kernel or libc/libpthread/C++ lib.
There are also functions and syscalls that it needs to replace. That needs to be a fully functional replacement, not just looking the same as in mocking.
I don’t have any exact figures. The number of syscalls varies quite a lot by platform and on most platforms there are many obsolete syscalls that are not implemented. At a rough guess, I’d say there are something like 300 syscalls and 100 lib calls that are handled of which 3/4 are wrapped and 1/4 are replaced.
> Valgrind is a mock of standard library/OS functions and I think its existence is a good thing.
That is mostly wrong.
Valgrind wraps syscalls. For the most part it just checks the arguments and records any reads or writes to memory. For a small number of syscalls it replaces the syscall rather than wrapping it (for instance calls like getcontext where it needs to get the context from the VEX synthetic CPU rather than the real CPU).
Depending on the tool it can also wrap or replace libc and libpthread functions. memcheck will replace all allocation functions. DRD and Helgrind wrap all pthread functions.
I agree that C is a basket case when it comes to safety and security.
The CPU and the hardware don’t care how confident C coders are in their ability.
C developers tend to forget the reason why Windows and UNIX like systems are now quite robust is that there has been over 50 years of turd polishing. Unfortunately for rust it is not immune to bugs other than memory safety issues. I think that it is a good idea to write new code in rust. Less so for battle hardened old code.
C++ is somewhere between C and rust. With modern ‘good practices’ (no raw pointers, no for loops) it can be an order of magnitude or two safer than C.