💾 Archived View for republic.circumlunar.space › users › dbane › gemlog › 2021-04-24.gmi captured on 2024-07-09 at 00:16:27. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-03-01)
-=-=-=-=-=-=-
Even if I'm mainly interested in rewriting programs with an attack surface in Lisp, there is another class of programs with light security requirements. In this case rewriting may not be required, and reworking existing C code is fine.
Non-extensible text editors may be a good case study. I usually use Emacs or vi, but learners might find those intimidating when they're supposed to be learning a language instead. To try solve this problem, Easy-ISLisp comes with a bare-bones text editor. I worked on this for a while to try harden it. The main tasks were something like the following.
These are some things I used previously and know work:
There should be nothing surprising here. The interesting stuff for me was things I hadn't managed to do successfully before, described in the following.
To be more precise, Embedded C++. Also note that I treat it as a multi-paradigm language so feel no need to use OO design unless it seems worthwhile.
This does look like a win. I changed temporary strings from `char` arrays to instances of the `string` class. This should prevent some errors.
This had two parts. The first was adapting file I/O to use the `ifstream` and `ofstream` classes. This was fine, but aside from the code looking a little nicer it doesn't seem to have made much difference.
The second was the use of the stream insertion (`<<`) and extraction (`>>`) operators. This had a higher payoff. It probably wasn't really a problem, but using `printf` when `puts` or `putchar` would suffice slightly bothers me. This problem just disappears. On the other hand, I had to throw out a lot of this code later to use curses (see below).
In this instance, curses (I've replaced regexp libraries similarly in the past).
I followed some familiar steps here:
and some new ones:
However, I still have quite a bit of testing before I would consider it usable. There was a lot of churn.
I think I did improve the editor a bit. But it was slightly more work than I expected, I don't know if it would pass cost/benefit for something larger, like the interpreter itself.
It is tempting to do something like the above for code you want to put on the Internet too. For example, spend some time hardening OpenCOMAL. But I think this would only work for use cases without a remote attack surface. In an unsafe language I don't think you'd ever finish and a rewrite seems best. A silver lining is you can do refactoring as in "Software Design for Flexibility" then.