summaryrefslogtreecommitdiff
path: root/CMake
diff options
context:
space:
mode:
authorThorbjørn Lindeijer <thorbjorn@lindeijer.nl>2011-04-09 20:35:35 +0200
committerThorbjørn Lindeijer <thorbjorn@lindeijer.nl>2011-04-10 13:22:57 +0200
commit289c0874808d79c995a8bbbe12d19e7245b7fb81 (patch)
tree4fc0bd2c3d7f9b601afc329c16d465a9b8096957 /CMake
parenta7702e97b48037a61f191ad5d2bab127a06fe96a (diff)
downloadmanaserv-289c0874808d79c995a8bbbe12d19e7245b7fb81.tar.gz
manaserv-289c0874808d79c995a8bbbe12d19e7245b7fb81.tar.bz2
manaserv-289c0874808d79c995a8bbbe12d19e7245b7fb81.tar.xz
manaserv-289c0874808d79c995a8bbbe12d19e7245b7fb81.zip
Fixed infinite loop in deserializeCharacterData
Could happen on servers where a character is being communicated that has something equipped. The infinite loop was due to using "while (msg.getUnreadLength())" on a message after having read one byte too much, causing it to miss the 0 bytes unread and count to minus infinity. This is a danger that we should probably also fix generally. The byte that was read too much was equipmentInSlotType, which I think should have been the number of items equipped in a certain slot type. This number is never written by the serializeCharacterData function and also doesn't seem necessary. When multiple items are equipped in a single equipment slot type, there will simply be multiple pairs transmitted for that equipment slot type. Reviewed-by: Freeyorp
Diffstat (limited to 'CMake')
0 files changed, 0 insertions, 0 deletions