dbremner

I'm developing an application that utilizes a genetic algorithm to optimize compilation flags.

I'm rewriting a suite of network applications from C++ to Rust as a learning exercise. It's a long obsolete and obscure protocol, so the results aren't particularly useful, but it's been a good introduction to the language.

This is a 30+ year-old codebase that originally started as pre-ANSI C. The design tradeoffs were very different at the time. I've managed to compile it as C++23 with unreasonably high warning levels, and it's now warning-free. However, there are still many unresolved issues.

One notable limitation is the use of a SIGINT handler implemented with setjmp/longjmp, which reduces the effectiveness of RAII.

Regarding textToStr, there were four instances where it was called twice in the same expression. To avoid potential problems, I replaced these calls with a temporary std::string to store the result of the first call before the second is made. In hindsight, none of these cases likely would have caused issues, but I preferred not to take risks. The SigIntGuard ensures that the std::string destructor runs even if a SIGINT occurs:

    {
        SigIntGuard guard;
        std::string const member{textToView(textOf(fst(b)))};
        std::print(errorStream, R"(No member "{}" in class "{}")", member, textToView(klass(c).text));
    }

Here is a real safety issue that I found and fixed a couple weeks ago. This is an ancient language runtime which originally ran on MS-DOS, Amiga, Atari, and at least a dozen now-discontinued commercial Unices. I've been porting it to 64-bit OSes as a weekend hack. While this particular issue is unlikely to appear in modern applications, a similar pattern might manifest today as a use-after-free error with std::string_view or an invalid iterator.

Background:

    typedef int Text; 

The Text type is used to encode different kinds of string-like values. Negative values represent a generated dictionary. Valid indexes in the string intern table (https://en.wikipedia.org/wiki/String_interning) represent a stored string. Other values represent generated variable names.

const char *textToStr(Text t) - This takes a Text value and returns a pointer to a null-terminated string. If t is a string intern index, then it returns a pointer to the stored string. If t represents either a generated dictionary or generated variable name, then it calls snprintf on a static buffer and returns the buffer's address.

Problem:

The use of a static buffer in textToStr introduces a temporal safety issue when multiple calls are made in the same statement. Here’s an excerpt from a diagnostic error message, simplified for clarity:

    printf(stderr, "Invalid use of \"%s\" with \"%s\"",
                textToStr(e),
                textToStr(s));

If both e and s are generated dictionaries or variables, then each call to textToStr overwrites the static buffer used by the other. Since the evaluation order of function arguments in C++ is undefined, the result is unpredictable and depends on the compiler and runtime.

I'm not sure about static analyzers, but here are the clang warnings I use for my personal C++20 projects. You will get an enormous number of warnings from typical C++ code. I doubt it would make sense to use these settings in a commercial environment.

-Weverything - this enables every clang warning

-Wno-c++98-compat - warns about using newer C++ features

-Wno-c++98-compat-pedantic - warns about using newer C++ features

-Wno-padded - warns about alignment padding. I optimize struct layout, so this warning only reports on cases I couldn't resolve.

-Wno-poison-system-directories - I'm not cross-compiling anything.

-Wno-pre-c++20-compat-pedantic - warns about using newer C++ features

https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.

https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.

Porting 16-bit assembly is harder but porting C code from Win16 to Win32 is pretty easy.

https://github.com/dbremner/cake is a 16-bit Windows 1.0 application that I ported to Win64; most of the changes weren't required.

I don't think it has all of them, but [0] is a tarball from Research Unix that has some Writer's Workbench source code.

The files are in cmd/wwb.

Other tarballs may have more Writer's Workbench code but I haven't looked at them.

[0] https://www.tuhs.org/Archive/Distributions/Research/Dan_Cros...

There is a complete list of passes here[0]. It does some optimizations but much less than a mainstream C or C++ compiler.

[0] https://github.com/golang/go/blob/master/src/cmd/compile/int...

My side project is a fork[0] of an old Java Swing app. I have been updating the code to use newer Java features and rewriting portions of it in Scala.

[0] https://github.com/dbremner/JavaPH

ReSharper (and presumably IntelliJ) supports expression-based search and replace.

Here are some commits where I used it to remove boilerplate from some test cases. The code was written long before MSTest added support for Assert.ThrowsException.

https://github.com/dbremner/PowerCollections/commit/a364a154...

https://github.com/dbremner/PowerCollections/commit/1de2f916...

https://github.com/dbremner/PowerCollections/commit/183e3c7c...

Here is a character encoding issue that I ran into about a year ago.

git does not support UTF-16LE[0]. The result is that UTF-16LE encoded files will be mangled[1] by the line ending conversion. There is at least one generated Visual Studio file (GlobalSuppressions.cs) that is saved in UTF-16 by default.

[0] https://github.com/libgit2/libgit2/issues/1009

[1] https://github.com/Microsoft/Windows-classic-samples/issues/...

I am writing an interpreter for Gedanken (https://news.ycombinator.com/item?id=8443298).

I have been hacking on CLR Profiler (https://clrprofiler.codeplex.com/) so that it uses less memory, leaks fewer resources, and is faster.

Is http://maclisp.info/pitmanual/hunks.html helpful?

John R. Ellis' doctoral thesis - Bulldog: A Compiler for VLIW Architectures (http://www.cs.yale.edu/publications/techreports/tr364.pdf) is an example of excellent technical writing.