Jim Huang

The article [Pretty-Printable Enumerations in Pure C](https://hirrolot.github.io/posts/pretty-printable-enumerations-in-pure-c.html) shows several C macro tricks, and we might benefit from them.

I checked the executable file specified in `LWAN_PATH` of `script src/scripts/benchmark.py`. It was not built with `make testrunner`. Instead, the appropriate path would be `build/src/bin/testrunner/testrunner`.

Related: #270

Thank @JackyYin for prompt reply. I would send a pull request on explicit prerequisites for target `testsuite` and `benchmark` later.

An effective evaluator is required for parsed expression. Which parts of C front-end would be modified to fit?

The idea is generally making sense. However, we should take the lazy evaluation way. By using eager evaluation, the `cfront` aggressively computes all the expressions, that would cause unexpected work....

> And I am curious about why **eager evaluation cause unexpected work**? We need to evaluate it anyway, what is difference to do it in advance? Lazy evaluation (or call-by-need)...

Thanks for pointing this. I've never analyzed the internals. Feel free to submit potential improvements over look-ups.

Can you use GDB to narrow down the problem? ```shell gdb -q out/shecc ``` Then, execute the following command inside GDB: ```shell run --dump-ir -o out/shecc-stage1.elf src/main.c ``` The program...

> ```shell > (gdb) run --dump-ir -o out/shecc-stage1.elf src/main.c > Starting program: /initrd/mnt/dev_save/descargas/shecc-master/shecc-master/out/shecc --dump-ir -o out/shecc-stage1.elf src/main.c > > Program received signal SIGSEGV, Segmentation fault. > 0x00000000004012a6 in add_block (parent=parent@entry=0x0,...