dstep VS jotai-benchmarks

You might also be interested in dstep, a tool that can generate D bindings from C header files.

- C, Objective-C = https://github.com/jacob-carlborg/dstep

> its test blocks make unit testing trivial to integrate.

Again, D also has this:

https://tour.dlang.org/tour/en/gems/unittesting

  void main() {

It's a C lib, generating bindings is super easy https://github.com/jacob-carlborg/dstep

There is no need to maintain bindings that can be automatically generated, wich can easily get outdated if the C project is actively developped

Anyways, someone went a ahead and updated it: https://github.com/Soaku/raylib-d

Not quite as seamless as Zig, but dstep is an external program that leverages libclang to do the same thing (and generates a D module for you), as well as e.g., smartly convert #define macros to inlineable templates functions :)

https://github.com/jacob-carlborg/dstep

But let me suggest Jotai to you. That's a collection with about 30K C programs. They all run without undefined behavior (as per kcc or frama-C). Each program is self-contained. But each program also runs for a very short time. So, I recommend you use CFGGrind to count the number of instructions executed. CFGGrind can separate instructions per function, and each Jotai benchmark consists of a single function. For instance, to count the total number of instructions executed by function foo, you can do (assuming that profile data was saved into a file called `test.cfg`):

We, at UFMG, have been working on a methodology to generate benchmarks in C. We have a working collection of benchmarks here with a bit more than 30K executable programs. Benchmarks are single functions mined from open-source repositories. We have designed a domain-specific language to generate inputs for them. We use psyche-c to infer missing types and declarations. We use kcc and AddressSanitizier to filter out as much undefined behavior as possible. We use CFGGrind to check input coverage and to count the number of instructions executed. These benchmarks can be used in many ways: to stress test compilers; to autotune predictive compilation tasks; to analyze the dynamic behavior of programs; to improve compiler optimizations; etc. We have a technical report here.