Why not just have the compiler zero the memory, and thereby remove the trap? Seems very sensible to me. Do you think it’s a bad idea, and if so, why?
As a type qualifier keyword:
{ int x, y; /* x and y are zero */ }
{ int noinit x, y; /* x is indeterminate, y is zero */ }
{ noinit x, y; /* both x, y indeterminately-valued */ }
{ int x, y = noinit; /* x zero, y indeterminate */ }
decl (unspec_order) { /* comma-separated list of decl items */
a[i] = i++; /* UB */
}
a[i] = i++; /* well-defined */ static int x, y; /* x and y are zero */Oh no no no, I was picking on hermitdev's characterisation of the behaviour. Sure, what the compiler does with the padding bytes is unspecified. But it can still lead to undefined behaviour, if some unwary user ever reads them. A misinterpretation like that, and poof you get a security vulnerability. The C standard is insane.
Modern processors, with their out-of-order execution, complex caching algorithms, deep pipeliens and multi-threaded hardware often render this sense of control more illusory than factual, but the C culture remains wedded to the idea that the programmer is in control.
Accordingly, it's pretty provocative to suggest that a compiler or runtime would zero out memory without you specifically saying so. Any C programmer can overload malloc (doesn't zero memory) to calloc (which does). Whether it's a good or bad idea to do so is up to the programmer. The overall idea is don't do anything unless I say so.