Re: Memory protection between compilation units?

On 2025-06-11 13:32:39 +0000, Mateusz Viste said:

This might not be a strictly C question, but it definitely concerns all
C programmers.
 Earlier today, I fixed an out-of-bounds write bug. An obvious issue:
   static int *socks[0xffff];
   void update_my_socks(int *sock, int val) {
    socks[val & 0xffff] = sock;
  }
 While the presented issue is common knowledge for anyone familiar with
C, *locating* the bug was challenging. The program did not crash at the
moment of the out-of-bounds write but much later - somewhere entirely
different, in a different object file that maintained a static pointer
for tracking a position in a linked list. To my surprise, the pointer
was randomly reset to NULL about once a week, causing a segfault.
Tracing this back to an unrelated out-of-bounds write elsewhere in the
code was tedious, to say the least.
 This raises a question: how can such corruptions be detected sooner?
Protected mode prevents interference between programs but doesn’t
safeguard a program from corrupting itself. Is there a way to enforce
memory protection between module files of the same program? After all,
static objects shouldn't be accessible outside their compilation unit.
 How would you approach this?

The traditional method to ensure that a program or a part of a program
does not do what it must not do is testing. In this case the tester
must modify the code so that the array socks is a part of a larger
data structure and and call update_my_socks with different values for
val, including the critical values -1, 0, 0xfffe, and 0xffff.
--
Mikko