this._z is used uninitialized in MersenneTwisterEngine.opCall

[WebDrake]

The _z field of the MersenneTwisterEngine is uninitialized on struct creation:

mir-random/source/mir/random/engine/mersenne_twister.d

Line 107 in b518dbb

private Uint _z = void;

The constructor does not touch it directly, but calls popFront(), where in this first call, _z is used to set the value of z without _z itself having been initialized first:

mir-random/source/mir/random/engine/mersenne_twister.d

Line 153 in b518dbb

auto z = _z;

Presumably the intention/expectation is that _z should be initialized to data[index] in the constructor?

[WebDrake]

Note that the effect is unobservable because the variate generated is never used (opCall is called from the constructor without its return value being used, and at the end of that opCall _z is set to a sane value). However, this should arguably be fixed, since it's technically undefined behaviour.

[WebDrake]

Further note: my own benchmarking of this suggests that performance actually improves slightly if _z is removed entirely, and L153 is replaced by

auto z = data[index];

Happy to submit a patch with that solution if it would be acceptable.

[WebDrake]

Further note: my own benchmarking of this suggests that performance actually improves slightly if _z is removed entirely

... with a side benefit being that opCall no longer needs to be called from the constructor.

[9il]

Presumably the intention/expectation is that _z should be initialized to data[index] in the constructor?

_z is not data[index] it is data[previous_index]

[9il]

Further note: my own benchmarking of this suggests that performance actually improves slightly if _z is removed entirely, and L153 is replaced by

Please check checksums

[9il]

The only reason to init _z is CTFE-able Mt, will init it with zero

[9il]

Done 5a5e66e