Why does putting an array in a Box cause stack overflow?

[EdmundsEcho]

I understand why you are hanging on the name of the function. Based on the Rust rule for when not to use it, one might consider the name being set_to_init() or the like. That way, the rule for when to use (or not), aligns with the name. I.e., don’t use set_to_init() if in fact the memory is not initialized. I’m not advocating one name over the other, but I get your point. - E

[ZiCog]

@EdmundsEcho

one might consider the name being set_to_init() or the like.

I'm not sure that 'set_to_init' changes the impression on me noticeably. I can't think of any better name. I was thinking using 'ready' or 'valid' or some such, as we do for signals in digital logic design. Not any better really.

One thought did cross my mind which makes me more comfortable about all is this:

What if, my 'T' was not a simple integer or array of integers? What if it was a reference or some complicated structure containing references. Essentially pointers. Then one could have serious UB by writing to those when they have not been given valid values. As every C programmer knows.

In that light 'assume_init()' looks very wrong if those pointers are not actually initialized.

[amos]

@ZiCog

I assume it has created my thing somewhere in memory. There are no UB warnings on that.

@ZiCog

'a' is uninitialized. But the request is to assume_init. Which implies that back in 'safe' land the compiler has to assume it is initialized, no matter what value it may hold.

I believe these are the incorrect assumptions that make it seem as if it can calling assume_init can be enough to make a initialized. Before you initialize it, your thing doesn't necessarily exist "somewhere in memory", and therefore doesn't "hold some value". Assuming so is relying on implementation details, where 1) declaring a variable allocates some place in memory for it, and then 2) this place in memory contains some random value. But this is never guaranteed. The second assumption is untrue in LLVM's memory model, where as explained above, memory can also contain undef - this is not yet physical memory! AFAIU, the first assumption is also untrue, as the compiler can "remove" "unnecessary" variables, for example in constant folding or unused variable elimination, and then they never get allocated in memory. Edit: even simpler, it can decide to store this variable in a register, which (as pointed above, TIL) might under some architectures not contain a value.

(I'd guess that unused variable elimination probably happens in the example alice gave: After removing the two conditionals because a can have the wrong value for each - it was never set to anything which contradicts this - it is also unused and can therefore be eliminated completely. So in the end, it really isn't allocated anywhere in memory. But this may sound circular, because it only happens due to the "contended" UB).