Re: Memory protection between compilation units?

On 15.06.2025 15:57, antispam@fricas.org wrote:

IIUC in your example the array was global, so compiler knew its
bound and in principle could generate bounds checks.  But
I am not aware of C compiler which actually generate such
checks. 

There was one apparently as early as 1983 :)
https://www.doc.ic.ac.uk/~afd/rarepapers/KendallBccRuntimeCheckingsforC.pdf
Granted, it wasn’t a full-fledged C compiler, more of a bounds-checking code
 generator. Still, the paper is a fascinating read and highlights that this
 topic has been explored for quite some time. A more recent variation on the
 theme can be seen here (based on GCC BP, abandoned a couple years ago):
https://www.cs.purdue.edu/homes/xyzhang/fall07/Papers/TR181.pdf
That said, detecting out-of-bounds array access is no panacea. Memory
 corruption can arise from various sources, such as dangling pointers or
 poorly managed pointer arithmetic. Hence why I was looking in the direction
 of the MMU. All compilation units of a program share the same set of TLBs.
 I figured there might perhaps be a way to isolate a given compilation unit
 in different TLBs, effectively sandboxing its memory, then make this unit
 communicate with the rest of the program via shm when shared memory
 accesses are needed.
Of course, even if such solution would be possible, it would not be very
 practical. Besides, one could easily achieve the same isolation by turning
 that compilation unit into a standalone, service-providing daemon.
Mateusz