Towards strictly compliant usage of container

The

This definitely doesn't affect pointer arithmetic and was not the case OP was referring to.

Type #2 - Provenance or other metadata embedded into the pointer

Here's the draft for "A Provenance-aware Memory Object Model for C". It describes the idea behind implementing pointer resolution provenance in C.

There's a quote discussing member offsets:

Pointer member offset Given a non-null pointer p at C type τ , which points to the start of a struct or union type object (ISO C suggests this has to exist, writing “The value is that of the named member of the object to which the first expression points”) with a member m, if p is (π, a), the result of offsetting the pointer to member m has the same provenance π and the suitably offset a.

Combined with two later statements about pointer arithmetic:

Pointer addition and subtraction Pointer arithmetic (addition or subtraction of integers) preserves provenance. The resulting pointer value is indeterminate if the result not within (or one-past) the storage instance.

Pointer difference Pointer difference is only defined for pointers with the same provenance and within the same array...

And the fact there are no proposals to change section 6.2.5 in the ISO standard that discusses pointer arithmetic.

Leads to the only possible conclusion, which is this is ok.

A different question would be whether or not the (char*)(ptr) operation violates strict aliasing rules.

Strict aliasing definition (just in case), from a different stack overflow post:

"Strict aliasing is an assumption, made by the C (or C ) compiler, that dereferencing pointers to objects of different types will never refer to the same memory location (i.e. alias each other.)"

But because the operation is within the same struct and we only use it for compile-time calculations, this is ok.

CodePudding user response：

If the formal term you are looking for is strictly conforming, then that means no forms of poorly-defined behavior may be present. In case your examples depend on alignment/padding considerations, then they have implementation-defined behavior and are not strictly conforming for that reason.

Otherwise, C allows all manner of object pointer conversions under C17 6.3.2.3/7:

A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. Otherwise, when converted back again, the result shall compare equal to the original pointer. When a pointer to an object is converted to a pointer to a character type, the result points to the lowest addressed byte of the object. Successive increments of the result, up to the size of the object, yield pointers to the remaining bytes of the object.

The "converted back again" rule guarantees that no "meta data" is lost.

This rule also means that we are allowed to inspect a struct by using a character pointer, but it is indeed questionable to start that inspection anywhere else than at the beginning. An int* pointer into the middle of the struct has to be regarded as just an int* and not as a pointer to an "aggregate" type, so we may not access it out-of-bounds (iterating below the address pointed-at).

Rather, to make sense of the above rule we must be free to regard the struct as a
char [sizeof(the_struct)], or we'd get in trouble with the rules for pointer arithmetic (stated below C17 6.5.6). But to do that we need to start out with a pointer to the struct indeed.

As for the "strict aliasing rule" (6.5/7), it only applies when doing an lvalue access, so it is mostly not relevant here. Also it has special exceptions for accessing something as a character type.

So your assumptions all seem correct as per the above quoted rule 6.3.2.3/7, and they don't violate pointer arithmetic nor strict aliasing.

Regarding type safety, perhaps you could implement the macro in standard C like this:

#define member_of(ptr, type, member) \ _Generic((ptr), type*: (type*)((char*)(ptr) offsetof(type, member)) )