Write optimizations also creates issues for implementations which require data to be initialized before reading. Every fully standard-conforming C application is such an implementation. Both C90 and C99 allow “trap values”, and therefore conforming applications must be prepared for an uninitialized location to contain one of those. Reading a trap value may cause an abend. (It is safe, in standard-conforming C, to write to a location containing a trap value.)
The requirement that locations be initialized before reading occurs in other implementations. Any implementation that has a “universe” of “safe” values, may require special precautions. The required precautions may amount to a need to initialize “uninitialized” values. A practical example might be an implementation that expects all locations to contain a pointer which it can safely indirect from. In such implementations, just as in standard-conformant C, every stack location needs to be initialized before being read.
Due to write optimizations, an application cannot rely on Libmarpa’s step instructions to initialize every stack location before its first read. One way to safely deal with the initialization of stack locations, is to do all of the following:
Applications which try to optimize out some of these initializations need to be aware that an application can never assume that activity in the stack is safely “beyond” an uninitialized location. Libmarpa steps often revisit earlier sections of the stack, and these revisits may include reads of previously unvisited stack locations.