Because the type of tramreadbuffer is uint32_t, it’s not
appropriate to perform arithmetic on it with the old read size
which is in bytes.
This didn’t usually affect hm2 EXCEPT FOR bspi, because bspi
is the only user of the code that reaches hm2allocatetram_regions
with the oldtranread_size being nonzero.
(The analysis is just the same for the case of the write buffers)
For those following along at home, I added the bad code
in cf4f68997553422c40dea22ad916b82ff0254a7f and all 2.7 and master
branches are likely affected.
Closes: #451
#1 – andypugh 于 2018-07-05
I am glad you found this, I probably wouldn’t have noticed the problem. (I think pointer-arithmetic tries to be too clever). Presumably this was memsetting 4x as much memory as necessary, with fairly random consequences?