If what we are debating is "does Fil-C catch everything that is UB in standard C", then IMO the answer is "obviously not". I have not yet heard of Fil-C catching any of the UB around restrict, for instance.

But even outside restrict, I think this code has UB:

#include <stdio.h>
#include <assert.h>

struct S {
    int x;
    int y;
};

int main() {
    struct S s;
    s.x = 0;
    s.y = 10;
    int *xptr = &s.x;
    int *yptr = xptr + 1;
    assert(yptr == &s.y);
    printf("%d\n", *yptr); // UB! We did ptr arithmetic outside of an array.
    return 0;
}

I could be convinced that you can use char* to access surrounding parts of the object, but I don't see a way to interpret the standard that would make the above program well-defined.

I haven't found an online playground for running Fil-C so I can't easily probe it to compare it with my understanding of UB in C, or I'd suggest more daring examples. But from the discussion here it sounds very much like Fil-C will not complain about the above program.

From my admittedly rather cursory looks at it so far, Fil-C is a UB-free standards-compliant C implementation (which is very impressive), but that does not mean that Fil-C can catch all UB -- in many cases it is UB-free by defining the behavior, which is totally standards-compliant but also very different from e.g. Miri which aims to catch all UB in Rust.

(And incidentally what is the point of offsetof() if not to support jumping around a structure like container_of()?)

That would be a good question to ask the committee. :)

Since then we’ve been trying to work out where is the wording in the standard that allows the kind of pointer arithmetic that is essential for it to be possible to copy an object as an array of character type. (Because if it’s possible then the struct User name buffer overflow earlier in this thread is not UB,

That doesn't follow. The parts of the standard that allow you to copy an object "as" an array of character type are 6.3.2.3 (a pointer to x for any x can be converted to a pointer to char, and you can increment the pointer up to the size of the object to access each each byte of the object) and 6.5 (strict aliasing rule exception for accessing any object via an lvalue of char type). That's all you need to copy an object as an array of character type, but even together they do not imply that converting a subobject pointer to a char * lets you walk outside the bounds of the subobject, or that if strcpy is passed a pointer to a subobject that it can walk past the bounds of that subobject (it explicitly can't).

Even if it's intended to be implied that each object is overlapped by an implicit char array - and that's already not really certain - it doesn't mean that converting a pointer to a subobject into a char * yields a pointer into the middle of the containing object's associated char[]. Rather it may point at the subobject's own associated char array, which overlaps the subobject and partially overlaps the containing object (and associated char array). Yes, these arrays must have addresses in common, but since this logic already relies on the existence of overlapping objects, it doesn't mean that a pointer to one is also a valid pointer into the other, or at least it doesn't allow bypassing the 'you cannot walk a pointer past the end of an array' restriction which is explicit in 6.5.6 - I.e. if you have a pointer into a char[] that covers only the subobject, then going outside the bounds of that array is UB.