Stop out-of-bounds read, and ensure all bytes are used, in FuncIntRandomMT

[ChrisJefferson]

This stops FuncIntRandomMT from reading off the end of a bag.

This isn't (currently) an actual problem, as it only reads up to a word-size, which is fine in GASMAN.

This appears to be (based on valgrind testing) the only place where we read a bag in word-sized chunks, where it's not reasonable to make sure the bag is word-sized at construction time.

[codecov]

Codecov Report

Merging #2716 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #2716      +/-   ##
==========================================
+ Coverage   75.75%   75.75%   +<.01%     
==========================================
  Files         478      478              
  Lines      241451   241459       +8     
==========================================
+ Hits       182902   182913      +11     
+ Misses      58549    58546       -3

Impacted Files	Coverage Δ
src/intfuncs.c	93.61% <100%> (+0.16%)	⬆️
src/stats.c	89.62% <0%> (+0.19%)	⬆️
hpcgap/lib/hpc/stdtasks.g	63.93% <0%> (+0.51%)	⬆️

[ChrisJefferson]

While adding tests (which I should have done in the first place), I found a small bug in this method -- it would round the length of the string down to the nearest multiple of 4, except when the string was of length less than 4.

I added a commit which fixes this. This will want to be mentioned in the release notes as it could change random numbers, but only because we are now using the whole string.

I could pull this into two PRs if anyone prefers that.

[markuspf]

Can this change "random" numbers? If so that should be noted in the release notes.

[ChrisJefferson]

The original part of this PR (don't read off the end of bags) wouldn't change random numbers. The second commit (I realised we aren't actually using all the string given) will change random numbers, when generated from a string which satisfies len(s)>4 and len(s)%4 != 0. I don't know how many such strings have existed in the past, but they certainly could :)

[fingolfin]

I think most such strings would have been obtained by querying the current state of the RNG, and thus its len would have been a multiple of 4. So I think this is fine, but it really should be documented explicitly in the release notes.

[fingolfin]

@ChrisJefferson could you please add it to the 4.10 release notes then (in the wiki)?

[ChrisJefferson]

done