[0x09]

The linked discussion on the memory model is particularly interesting to me as it covers a number of issues and ambiguities with the current specification for strict aliasing and what kind of accesses should/shouldn't be allowed, including for example the problem that there's no way to obtain untyped space on the stack (Q75).

Since this as a whole is among the least consistently implemented and (arguably based on the number of questions it generates) least well understood aspects of the standard it's nice to see some authoritative efforts to clarify the intended behaviors.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2294.htm

[saagarjha]

> the problem that there's no way to obtain untyped space on the stack (Q75)

As in a standard alloca?

[gpderetta]

Fun fact: alloca is neither in (any) C standard or POSIX. It is just a very old extension, implemented in many compilers with somewhat compatible, under specified semantics.

[saagarjha]

I am aware of that, which is why I said “a standard alloca” instead of “the standard alloca”. I’m asking if they’re proposing adding a version of alloca to the standard.

[pjmlp]

Very old indeed, Turbo C 2.0 for MS-DOS already had it.

Not sure about the Small C dialect from early 80's.

[aidenn0]

While you can't get untyped space on the stack, it is explicitly permitted for objects of character type to alias objects of other types. I don't see how effective_type_3.c has undefined behavior.

[comex]

The aliasing rule isn’t symmetric: you can access objects originally declared as types other than char using char pointers, but you can’t access objects originally declared as char using non-char pointers. (And malloc()ed buffers are neither of the above and have their own rule.) Here’s a blog post explaining it in more detail:

https://gustedt.wordpress.com/2016/08/17/effective-types-and...