[p_l]

It's not UB. It's also not covered by standard - it's implementation-specified. What will happen is dependant on decision of compiler writers.

It is, however, not the only way to write to memmapped registers.

The original C way of doing so was to use an assembly function wrapping the actual act of reading/writing (honestly, better than doing the above, as it helps making it very explicit how the write will happen as well as abstracting any details like needing to add a barrier or whatsoever), the other way was to specify the symbol with address of the memmapped register in assembly, and link resulting object with C code.

A C implementation is, AFAIK, free to refuse the literal addresses used as pointers and pass as ISO C.

[rfoo]

Both of the alternative do not generate same code though.

At least they don't without LTO.

[p_l]

The point of "implementation defined" is that the actual code generated is up to implementation, or in fact whether it even accepts such code.

[rfoo]

Sure, I don't disagree.

What I mean is, most compilers won't generate a function call or an additional indirect memory access for *(111) = 222;, unlike your spec-compliant alternatives.

This is, IMO, the problem. Sometimes we just want a more ergonomic way than inline assembly in a hot loop (and also we'd like to to pretend its portable). The spec does not have an answer to this.

So, unless all C compilers in the world actively sabotage this usage (like how Go did to map traversal orders), your spec saying this is "implementation defined" have no impact at all. All C compilers are bound to implement the same intuitive but completely-not-enforced-by-spec behavior. Because if they don't, people just use something else.