Waiting for someone to say this wouldn't be possible in rust.
Spoiler alert: it would be.
Spoiler alert: it would be.
But this is a data race: the mail program performs a check on some data (in the filesystem) to establish some precondition, and then a concurrent thread of execution (another process) mutates that data before the mail program acts on its (now invalidated) belief.
LLVM wouldn't call it a data race, because to LLVM all system calls are essentially opaque. But if the filesystem only existed within your process, and were written in idiomatic Rust style, using structs, borrowing, mutability, and lifetimes, then the analogous bug (two threads racing and mutating the filesystem at once) would be prevented. The real villain here is shared mutable state; if UNIX had been written by skilled Rust progammers, it would with any luck have some abstraction that provides more isolation and less potential for interference than the filesystem.
> on some data (in the filesystem)
I think this is kind of absurd and my guess is you haven't worked on a filesystem driver. At a certain point there is value in admitting that race conditions are a part of the universe and developing strategies to deal with them, rather than waste a bunch of overhead trying to isolate a program from the real world or from itself. The semantics you seem to want would be really crazy for a filesystem.
I was attempting to parody the line that you see around here every time a vulernable C program is shown, that rust is magic pixie dust that removes all security issues. (This is exactly the type of bug that memory safe languages are still vulnerable to.)
(One could argue setuid is the real problem though.)
Had AT&T charged UNIX at the same prices as the other OSes, instead of giving it for free to universities and I hardly believe C would matter.
Most of the features people associate with C are compiler specific language extensions that any compiler writer can bother to add to his favourite language and not part of ANSI C.
Inline Assembly, CPU intrisics, SIMD, calling conventions, out of order execution, hardware transaction memory, cache line control, GPU execution, attaching functions to interrupt handlers and so on.
Also the pile of UB patterns that C compilers have accumulated throughout the years, and the differences between compilers, makes it actually easier to reason about code at the Assembly level than looking at C code.
The only thing has going for it, us that thanks to the economics of free, we now have UNIX flavours everywhere.
So we can only get rid of C when UNIX is not an option, and that is almost impossible.
Only now almost 30 years later has C++ surpassed C in many use cases, but it still carries C with it.
C could have been made so much safer with a few tiny changes, like having optional bounds checking and not decaying arrays into pointers.
...No, not especially. It may not expose CPU-specific functionality in the spec, which is why it is somewhat portable, but it still is effectively good at the same things asm is good at. That's why C is sometimes dubbed "portable assembly"
>Also the pile of UB patterns that C compilers have accumulated throughout the years, and the differences between compilers, makes it actually easier to reason about code at the Assembly level than looking at C code.
Well, yeah. Asm is rigorously defined. It's perhaps the only language that has absolutely zero UB in practice (many languages CLAIM to have no UB, but if you're on multiple architectures, it's almost unavoidable, although few have as much as C): because it's totally unportable, it doesn't have to lean on UB the way C does for optimization.
>Only now almost 30 years later has C++ surpassed C in many use cases, but it still carries C with it.
Yeah, but C++ has... other problems.
>C could have been made so much safer with a few tiny changes, like having optional bounds checking and not decaying arrays into pointers.
Now that's something I wish happened.
If you want good code, you need to think, in every language.
And I would go further and say: the people who prefer to leave details to others are exactly the people who will write filesystem race conditions like this bug and not understand what they have done.