from Hacker News

Tips for stable and portable software

by begriffs on 9/2/20, 2:52 AM with 63 comments

• by CJefferson on 9/2/20, 9:07 AM

  I've currently involved with a system, written in C, which has been going for 30 years: GAP - https://www.gap-system.org

  While I write a lot of C, I immediately disagree with the idea that C has a "simple (yet expressive) abstract machine model". Every so often we find a bug which has been present for over a decade, because some new compiler has added a (perfectly legal by the standard) optimisation which breaks some old code.

  Picking one example: in the "old days", it was very common (and important for efficiency) to freely cast memory between char, int, double, etc. For many years this was fine, then all compilers started keeping better track of aliasing and lots of old code broke.

  Also, while POSIX is a nice base, it stops you using Windows, and also almost every non-trivial program ends up with a bunch of autoconf (which has to be updated every so often) to handle differences between linux/BSD/Mac.

  Also, definatly don't distribute code where you use flags like '-pedantic', as it can lead to your code breaking on future compilers which tighten up the rules.

• by ut6Ootho on 9/2/20, 8:56 AM

  This article certainly rings a bell, as I started rewriting my personal projects to C in the last year, precisely because I wanted to make them decades-proof. I still use the same vimscripts I wrote in early 2000', I want the same thing for all my tooling and apps.

  I'm not sure it makes sense professionally, though, as most codebase won't survive a decade : after three years, the dev team will turn over, and the new team will want to rewrite everything from scratch. Or start rewriting parts of the exisiting system in a new language, until it ultimately eat it up. It may be related to the kind of companies I work with, though (very early stage startups).

  Regarding interfaces, I think the author could have gone a step further. There is actually a standard and portable interface system: html/js/css. If you write a dependency free web app using things like webcomponents and other standard techs, you know it will stand time, and it actually matches all the reason why the author want to use C : standard and multiple implementations.

• by ludocode on 9/2/20, 3:49 PM

  This is mostly good advice. I don't love configure scripts, I don't agree with the heavy reliance on POSIX if you intend to be compatible with Windows, and I don't love the fact that the author recommends third party data structure libraries that they haven't actually used. For container libraries in C, you really have to use them to get a feel for their usability (this sounds like a tautology but it's not.)

  I disagree strongly with one recommendation. This is just an example, but it holds for larger API design in general:

  > we could add a fallback to reading /dev/random. [...] However, in this case, the increased portability would require a change in interface. Since fopen() or fread() on /dev/random could fail, our function would need to return bool.

  No, definitely not. It is dangerous to expect the application to sanely handle the case of randomness being unavailable when it is never going to occur in practice. On all POSIX platforms, /dev/random exists and will block until sufficient entropy is available. Something would have to go seriously wrong for this to fail. This is so rare that any error handling code for it will never be tested. The most likely outcome of forcing the caller to handle it is that the return value is ignored or improperly handled and the buffer is used uninitialized, leading to a security vulnerability.

  My recommendation instead would be to error check your fopen() and fread() calls within get_random_bytes(), and print an error and abort() if they fail. This way if someone's system is improperly configured and /dev/random doesn't work the program will just crash. Same goes for macOS's SecRandomCopyBytes() and Windows' half a dozen calls to use an HCRYPTPROV. This way you still return void and there is no danger of callers improperly handling errors.

  In general, unless you're writing safety-critical software, it's fine for your code (or even library code) to abort() in these sorts of exceptional situations when there is no reasonable or safe way to handle the error. If someone truly wants to handle the error, they can just not use your API and do it manually.

• by kasperni on 9/2/20, 7:03 AM

  > Tips for stable and portable software

  I think a more accurate title would be "Tips for stable and portable C programs"

• by chrisco255 on 9/2/20, 7:08 AM

  From the title, I was hoping to hear about software systems that have powered infrastructure for decades, but unfortunately it was more of a programming language analysis strategy.

• by jankotek on 9/2/20, 10:28 AM

  Hm, decades is not that much, most enterprise code fits into that. But how about 200 years?

  It is about people. Documentation, paper trail why some decisions were made, archiving build tools, VMs, dependency source code..

  Also C, POSIX and Motif are terrible choice for their fragmentation. Java is very booring, but compiling and debugging 20 years old code is very common.

• by jart on 9/2/20, 9:59 AM

  That forceinline definition is just tip of the iceberg. It's so hard to define in a way that works with different versions of GCC, -Werror, instrumentation, MSVC, and profiling. If you care about portability, consider just not caring and using static. Too much special casing code can actually make it harder for people in weird environments to use your code, since something is going to break it, and reading past the ifdef soup becomes the biggest obstacle.

• by Cthulhu_ on 9/2/20, 10:01 AM

  I'm currently "betting" on Go for making a back-end (just a REST API + sqlite database) that will last a decade; I'm betting on the tooling to stay backwards compatible or with minimal changes in the codebase; I'm betting on the readability of my own code for the next decade, and I'm betting on the language + tools to continue to be developed whilst sticking to their original goals.

  Generics is going to be fun.

• by MaxBarraclough on 9/2/20, 12:04 PM

  Seems like good advice. I'd add another one that seems completely obvious, but some sloppy developers ignore it: avoid undefined behaviour. If you're going to work with C, you need to know about undefined behaviour and take it seriously.

• by iso8859-1 on 9/2/20, 11:06 AM

  Really weird that he recommends Motif. Motif is not comparable to Web/Gtk/Qt since it has only the most primitive widgets, and no 3D support.

  I would propose doing a web-app if you really care so much about compatibility. Web also allows for more custom widgets.

• by fjfaase on 9/2/20, 8:41 AM

  One day, maybe when I am retired, I am going to develop a programming language-agnostic algorithm specifying language with which you can generate code for programming languages ;-). A kind om Mathematica, but than for software.

• by divan on 9/2/20, 9:27 AM

  Obligatory mention of Ten Years Reproducibility Challenge https://github.com/ReScience/ten-years