Applied to CVS.
David Carter wrote:
Two separate bugs fixes, against current 2.3 CVS.
The missing i++ means that we would have failed to RESERVE some messages
where a given GUID appears multiple times in a mailbox. Not a huge deal.
The missing (i < count) was potentially serious: we fall off the end of
the ids array where RESERVE doesn't involve the last message in a mailbox.
I think that we got away with it. My reasoning follows:
If you are really unlucky 12/20 bytes of allocated but uninitiated
memory (ids[count]) will match one of the GUIDs later in the mailbox.
This will cause cmd_reserve() to reserve that message and issue a
spurious response.
Fortunately sync_client will moan and then ignore the response if it
wasn't expecting the GUID. If it _was_ expecting the GUID then
sync_server has reserved a legitimate copy. In fact this should be
impossible. If sync_client wanted a message with that GUID, it would
have asked for that copy in that mailbox, so the ids array would have
been longer.
ids[count] is always allocated.
There is a one in hundred chance that ids[count+1] is not, which would
lead to a segmentation fault if ids[count] matched a GUID.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
