gistfile1.c

/* To my understanding, the following is well-defined C:
 *
 *  given: */
int* p;

// then:
char* c = (char*)p;
char firstByteAtP = *c;
// firstByteAtP is the first byte at the pointer p.

// Put another way, aliasing through char* is OK; otherwise, memcpy could not be written.

// Now, my question: is the following code well-defined?

char* c;
intptr_t i;
memcpy(&i, &p, sizeof(p));
memcpy(&c, &i, sizeof(c));
char firstByteAtP = *c;

/*
 * That is, can you alias c to p through a memcpy?
 * If so, C precludes an implementation where a pointer to a wider type has a different implementation,
 * such as indexing assuming aligned access.
 *
 * Emscripten could realize significant code size reductions if it could represent 32-bit loads and
 * stores as HEAP32[p] instead of HEAP32[p >> 2], but that would require shifting the pointers whenever
 * statically casting between char* and int* (such as from the result of malloc).
 */

Not sure about the C++ aspect, but one reason emscripten does >>2 is to ensure the access is aligned, as typed arrays give wrong results on unaligned reads and writes, silently. For that reason asm.js requires it, to make it easy to optimize.

In non-asm.js code, we do support HEAP32[p], there is in fact an optimization doing it (that is deprecated) optimizeShiftsAggressive I think it was called. The benefits were not huge.

It is well formed because there are no intervening possibly aliasing accesses to i.