[bmcooley]

Same here. Embedded programmer, primary language being C. I sat here staring at that line for a solid 30 seconds trying to understand the intent - it’s nonsensical. I read your comment and see the intent you’re guessing at but… you would not generally write C like this. Pointer arithmetic is to be avoided, and this case is contrived. I don’t think a compiler warning would be thrown here though - maybe that is the point, that the language and compiler would not catch this issue and that typos or novice learners can make compilable mistakes too easily?

[remexre]

I mean, this surely wouldn't be written as obviously as this in real code. It'd be somewhere in a data structure that packs to be able to fit better in a cacheline, and has something like:

    struct edge {
        struct node* src;
        int dst_offset;
        int label;
    };

Knowing about integer overflow, the original programmer carefully wrote overflow checks where dst_offset gets computed, and the code was correct. Nodes were allocated into one contiguous array, and edges were allocated into another.

Later, someone else changed how nodes were allocated, so adding a new node would never trigger a realloc of the whole graph. Instead, a linked list of node arrays is allocated. Suddenly now, computing dst_offset is UB, and yet, the observed behavior of the resulting program is the same.

Even later, someone updated GCC on the CI machine, and now the inliner is more aggressive. Suddenly, mutations to node labels are unreliable, and edges are found to not refer to any node in the graph, except when debug logging logs the address they actually refer to.

This is the kinda thing that requires an understanding of UB that has nothing to do with the actual hardware to diagnose and fix, which I think is really unnecessary for a beginner.