aboutsummaryrefslogtreecommitdiff
path: root/backends/symbian/src
diff options
context:
space:
mode:
authorTorbjörn Andersson2006-03-14 20:09:32 +0000
committerTorbjörn Andersson2006-03-14 20:09:32 +0000
commit59b6f0f715fb9874858feb40a22b844e42a3ce79 (patch)
tree78fa52d978e025eb5af98b0bca38adcd07b16629 /backends/symbian/src
parentc12a5a35be96239668f1df6919d83c26587dd5e0 (diff)
downloadscummvm-rg350-59b6f0f715fb9874858feb40a22b844e42a3ce79.tar.gz
scummvm-rg350-59b6f0f715fb9874858feb40a22b844e42a3ce79.tar.bz2
scummvm-rg350-59b6f0f715fb9874858feb40a22b844e42a3ce79.zip
Fixed a potential bug that could cause memory to be read out-of-bounds.
(Unfortunately, this does not fix the Kyra bug I'm looking for.) In the most extreme case: * DR and RR will point to &DR_TABLE[60], and AR will point to &AR_TABLE[60] * SLOT->KSR will be 0 * CH->kcode will be 15 In that case, it will attempt to access AR[15], RR[15] and DR[15], i.e. AR_TABLE[75] and DR_TABLE[75]. So these arrays need to be 76 elements, not 75. We used to initialise element 75, but this was changed to 74 to match the size of the arrays. Buf if my reasoning is correct, it was the arrays that were too small. svn-id: r21301
Diffstat (limited to 'backends/symbian/src')
0 files changed, 0 insertions, 0 deletions