From: Dan Harkless <dan@harkless.org>
Date: Wed, 31 May 2000 02:27:40 +0000 (+0000)
Subject: Applied Alec Wolman <wolman@cs.washington.edu>'s dropsbr.c patch:
X-Git-Tag: kim-before-sasl~10
X-Git-Url: http://git.marmaro.de/?a=commitdiff_plain;h=1f90e5c5a3c7cb029ce1ac3c2e760c368fd2ce92;hp=1f90e5c5a3c7cb029ce1ac3c2e760c368fd2ce92;p=mmh

Applied Alec Wolman <wolman@cs.washington.edu>'s dropsbr.c patch:

  In the map_write routine, a call is made to map_open and this call is supposed
  to set the "clear" variable to 0 or 1, depending on whether the map file is
  empty or not.  In mh6.8.3, this worked because map_open would set "clear" by
  calling the mbx_Xopen routine.  In nmh, the code for mbx_Xopen was merged into
  mbx_open, but the interface for mbx_open doesn't support the clear variable,
  so that functionality was lost.  The map_open interface still contains "int
  *clear" in the prototype, but never sets it.

  My patch eliminates "clear" from the map_open interface (I checked to make
  sure that map_write is the only client of map_open).  Furthermore, my patch
  also sets the "clear" variable properly at the beginning of map_write by
  calling fstat().  This eliminates the bug in that the value of "clear" being
  used later in the routine was just stack garbage.

  Having a bad value of clear causes this next bug to be triggered: The fp file
  pointer was being opened with fdopen, but in two of the three switch cases it
  wasn't being closed.  In certain cases, this was causing packf to run out of
  file descriptors if you attempted to pack a large folder.
---