The Worm Ouroboros

For our file classification tool...we made it work from a System.IO.Stream, with the only requirement being that the stream was seekable, and we have it classifying hundreds of millions of filesystem-backed file streams per day, no problem.

So we recently shared it with a partner team, and all of a sudden in their environment, every once in a while they get a file that takes five minutes to identify. The difference turned out to be that their stream implementation was backed by a database, so even though it was seekable, every read turned into a database query, so if you passed in a big zip file with the directory information missing from the end, .Net would read through the entire stream backwards, looking for the magic number, one 32-byte read (database query) at a time...

> on a modern computer, a pointer dereference could very lead to the execution of Python code.

So the BEHAVIOR of the C code does not change. The dereference of the pointer triggers a memory page load, and if that load is successful, a numeric value is returned and added to the array. If the load fails, you will have the undefined result of accessing uninitialized memory.

In both cases, the behaviour of the code remains squarely within the C standard - with the actual result of the computation contingent on various external factors.

This can happen if the OS lets you use user-space file systems, the same way it can happen if you have custom hardware with memory-mapped temperature sensors (and suddenly your code literally “depends” on the weather).