[I tried to send this earlier, but was thwarted by list shenanigans. Apologies if it's a dup.] On Thu, Oct 19, 2017 at 10:52 AM, Ron Natalie <ron(a)ronnatalie.com> wrote: Gerard Holzmann has something on this that I think is great: http://spinroot.com/gerard/pdf/Code_Inflation.pdf - Dan C. PS: A couple of thoughts. The shell script hack on 7th Edition doesn't work if one tries to 'execl("/bin/true", "true", NULL);'. This is because the behavior of re-interpreting an execution failure as a request to run a script is done by the shell, not exec in the kernel. This implies that one could not directly exec a shell script, but rather must exec the shell and give the path to the script as the first argument. I vaguely recall we had a discussion about the origin of the '#!' syntax and how this was addressed about a year or so ago. I tried to write a teeny-tiny '/bin/true' on my Mac. Dynamically linked, the obvious "int main() { return 0; }" is still a little over 4KB. Most of that is zeros; padding for section alignment and the like. I managed to create a 'statically' linked `true` binary by writing the program in assembler: % cat true.s # /bin/true in x86_64 assembler for Mac OS X .text .globl start start: mov $0x2000001, %rax # BSD system call #1 mov $0, %rdi # Exit status: 0 = 'true' syscall # OS X requires a non-empty data segment. .data zero: .word 0 As I recall, % macOS requires you to have a data section aligned to 4K, even if you don't use it. The resulting binary is a little over 8K; again, mostly zeros. There are parlor tricks people play to get binary sizes down to incredibly small values, but I found the results interesting. Building the obvious C program on a PDP-11 running 7th Edition yields a 136 byte executable, stripped. Still infinitely greater than /bin/true in the limit, but still svelte by modern standards.