Compilable C Curry Challenge!

C and C++ are both statically typed. And thus it seems like a fun challenge to write a program in C or C++ that writes source code by looking in header files for functions to call and then randomly mashes them together and passes the results to other functions.

I wonder how long it'd take before you'd find a kernel bug this way.

Has anyone ever done this?

>>1
That could be useful, but since type requirements often go beyond the type system, you'd need extra hints. Also you might not want to run every possible combination. Some might be dangerous, like recursive_delete("~/"); Hand written unit tests are sufficient most of the time. Maybe some automation could be introduced but I'm not sure how much is possible.

Some might be dangerous

Which is why I'll be running everything inside of a virtual machine...

Most of these programs would just segfault. A lot of arguments can be passed that statically valid but will actually just end in memory violations, i.e., passing NULL to any of the standard library function that write to that pointer.

You would have to implement automatic error checking as well, otherwise you would also get segfaults or just nonsensical programs that would try to write to files that were never opened, and so on.

>>4
Is that so bad, though? I don't think >>1 is suggesting that these programs be run on any system of importance (since the goal of finding a kernel bug would defeat the purpose of that), so a few segfaults or attempted invalid writes should be no problem. I would imagine the setup would be a virtualized machine that continually generates programs, communicates them to the host, then executes them, leaving the host to detect whether Something Bad happened.

I think the real problem would be non-terminating programs and user input. Who knows? Maybe sleeping for more than 49482 seconds is a kernel panic on the 49483^rd! That's something I'd like to know.

>>5
The problem is the vast, vast majority would segfault almost immediately and due to similar causes. You're not really going to find any interesting bugs that way, if 99% of the generated code never gets executed because a memory violation happens in the first few lines.

>>6
That is true. Anything with a significant precondition (a file that has been mmap'd is truncated to a smaller size, or such) would be almost impossible to turn up like this.

You have to be a Curry Nigger to take part in the Curry Challenge.

Is it like the cinnamon challenge?