enumerate all kinds of undefined behavior, even that which cannot be safety-checked

[andrewrk]

The language reference should have a comprehensive list of every of possible undefined behavior that is possible, with a description of either how safety checks work for it, and under what circumstances the safety check will catch the problem or not, or the docs should explain why there cannot be safety checking for this particular kind of undefined behavior.

With this it will be obvious how close (or distant) zig is from a safe language.

[Mouvedia]

Most undefined behavior that cannot be detected at compile-time can be detected at runtime.

So you are saying that we need to add a no-safety sub section in https://ziglang.org/documentation/master/#Undefined-Behavior that will be continuously populated?
Do you have examples of such cases? e.g. from existing github issues

[hiroakitakada]

So you are saying that we need to add a no-safety sub section in https://ziglang.org/documentation/master/#Undefined-Behavior that will be continuously populated?

I believe that the subsection listing all no-safety behavior should be added.

Do you have examples of such cases? e.g. from existing github issues

#3180 is already mentioned above. Other examples are unsafe language constructs and builtin functions including (but, not limited to) the followings.

• undefined
• [*]T
• [*c]T
• @bitCast
• @intToPtr
• @ptrCast
• @memcpy
• @memset
• @fieldParentPtr