The sorry state of software quality

Thanks to a tweet by Aaron Toponce I learned about the Linux /dev/full pseudo-device. Write system calls to it always fail with a ENOSPC (no space on device) error. With it finding software that doesn’t check for failed writes is a piece of cake. Let’s see this in action.

Here is a program that outputs a simple message on its standard output.

$ ls --version
ls (GNU coreutils) 8.32
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Richard M. Stallman and David MacKenzie.

When its standard output is redirected to /dev/full the message write will fail. This program, correctly, outputs an error message on its standard error channel, and also terminates with a non-zero exit code. This causes the subsequent echo command to be skipped.

$ ls --version >/dev/full && echo Found a bug
ls: write error: No space left on device

Now brace yourself to see several popular programs that fail to handle this case correctly.

$ python3 --version
Python 3.9.2
$ python3 --version >/dev/full && echo Found a bug
Found a bug

$ npm --version
7.5.2
$ npm --version >/dev/full && echo Found a bug
Found a bug

$ java --version
openjdk 11.0.14 2022-01-18
OpenJDK Runtime Environment (build 11.0.14+9-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.14+9-post-Debian-1deb11u1, mixed mode, sharing)
$ java --version >/dev/full && echo Found a bug
Found a bug

$ javac --version
javac 11.0.2
$ javac --version >/dev/full && echo Found a bug

$ gcc --version
gcc (Debian 10.2.1-6) 10.2.1 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc --version >/dev/full && echo Found a bug
Found a bug

$ pandoc --version
pandoc.exe 2.12
Compiled with pandoc-types 1.22, texmath 0.12.1.1, skylighting 0.10.4,
citeproc 0.3.0.8, ipynb 0.1.0.1
User data directory: C:\Users\dds\AppData\Roaming\pandoc
Copyright (C) 2006-2021 John MacFarlane. Web:  https://pandoc.org
This is free software; see the source for copying conditions. There is no
warranty, not even for merchantability or fitness for a particular purpose.

$ pandoc --version >/dev/full && echo Found a bug
Found a bug

$ npm eslint --version
6.14.16
$ npm eslint --version >/dev/full && echo Found a bug
Found a bug

Such faults also exist on Windows (10), even for the programs’ primary output. Here are two cases tested using CygWin.

$ tasklist >/dev/full && echo Found a bug
Found a bug
$ which tasklist
/cygdrive/c/Windows/system32/tasklist

$ ipconfig >/dev/full && echo Found a bug
Found a bug
$ which ipconfig
/cygdrive/c/Windows/system32/ipconfig

Am I being pedantic examining these faults? I think not, for the following reasons.

First, there are cases where loosing even version output can be important. Imagine a script that logs the version of executed programs in a disk that has filled up.

Second, if the program doesn’t check for a failed write in the simple case of a version output, one suspects that other, more important, write (and other) errors may also be getting silently ignored.

Third, if several very popular programs fail in this way it means that catching these errors is a lot more difficult than it should be. Worryingly, these programs are written in diverse languages (C, C++, JavaScript, Haskell), and none of them seems to offer an easy way to get this right.

These errors are relatively easy to find and fix; I fixed them in the FreeBSD operating system date and echo commands back in 2003. However, the fact that they persist to this day, means that we need better ways to write software.

Comments   Toot! Tweet Share