Random thought. Another commenter worried about the runtime of the program becoming mangled and performing destructive operations on your machine. What if you run the reducer as a source-to-source Nix derivation? Protects against dangerous things, and can be easily distributed to remote builders.

Oh, that’s a neat idea. To reply to the sibling comment: Nix runs commands under a sandbox. It’s not bullet proof, but useful enough that it will prevent obvious commands like deleting local files and accessing the network.

It took some time to get RustPython to run, but it seems to work fine: https://gist.github.com/judofyr/82d2255c92ebb0c6b3a6882ac9fd...

Also, after running it for 5 minutes it was now able of reducing it to a much smaller case:

    class a:
        def b() : c
        def h(d) :
            while d:
                    break
            else:
                return 
            d.b()
    def j(e) :
        f = a()
        if f.h  () :
                g
    i = ""
    j(i)

You generally shouldn’t use absolute paths in your programs. That makes it dangerous for local development, and makes running two copies of the program to compare behaviors difficult.

There’s a Venn diagram of people who don’t care enough to do that (works for me!) and people who would never think to use c-reduce. It’s not a perfect circle, but it’ll be fairly close.

> You generally shouldn’t use absolute paths in your programs.

This is true, but I was enjoying the irony that there is an old sys-sdmin adage that you should only use absolute paths in your program(usually a shell script, in this environment) this is to make sure it is running exactly what you expect it to run.

So always put "/usr/bin/awk" instead of just "awk"

I had a co-worker once who took this as gospel. His scripts were always... interesting... to port to a new environment.

How does this protect against dangerous things?

My understanding is that this would just cause the dangerous things to be repeatable.

It must be that by running any program within the nix build sandbox you don't expose your files unless you discover a privilege escalation attack by chance during the reduction process.

FWIW shrinkray gets to 162 bytes if I leave it to run for about 10 minutes. https://gist.github.com/DRMacIver/ee025c90b4867125b382a13aaa...

I think it might do a little but not a lot better if I left it to run for longer but it looked to have mostly stalled then so I got bored and killed it.

I actually tried to Shrinkray it myself, but after ~3 minutes it crashed with the following stack trace:

      (4 nested BaseExceptionGroup: Exceptions from Trio nursery (1 sub-exception), and then:
      +-+---------------- 1 ----------------
        | Traceback (most recent call last):
        |   File "/nix/store/5cdw4sa0n0lwym47rd99a1q6b4dj7nr9-python3.12-shrinkray-0.0.0/lib/python3.12/site-packages/shrinkray/work.py", line 221, in parallel_map
        |     yield receive_out_values
        |   File "/nix/store/5cdw4sa0n0lwym47rd99a1q6b4dj7nr9-python3.12-shrinkray-0.0.0/lib/python3.12/site-packages/shrinkray/work.py", line 71, in map
        |     yield v
        | GeneratorExit
        +------------------------------------

Not sure if this is a known issue? Note that I ended up not respecting all of the version requirements in the pyproject.toml since I tried to run it all in Nix and there the Poetry support is currently quite lacking.

Interesting. I've not seen that before. My best guess is that it might be an old trio version or something, but I'm not sure.