From: sandmann AT clio DOT rice DOT edu (Charles Sandmann) Message-Id: <10109171546.AA17450@clio.rice.edu> Subject: Re: freopen/_creat(w2k) interaction [was: Re: Build problems] To: eliz AT is DOT elta DOT co DOT il Date: Mon, 17 Sep 2001 10:46:31 -0500 (CDT) Cc: djgpp-workers AT delorie DOT com In-Reply-To: <2561-Mon17Sep2001182058+0300-eliz@is.elta.co.il> from "Eli Zaretskii" at Sep 17, 2001 06:20:58 PM X-Mailer: ELM [version 2.5 PL2] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > Scenario (may not be real): > > I close handles 3 & 4 (stdaux,stdprn). I freopen a file structure that > > was on handle 5 - it will now be on handle 3. If someone expected a > > same handle (saved fileno or something) would not work. > > Getting 3 instead of 5 for the new handle is not different from > getting 6. Sure, but if you expect to get 5 back you will be broken. The expectation that freopen returns the same handle is based on a first free algorithm with nothing free below the handle, which can be wrong if you have freed other handles in the low space (3 & 4). Since _creat also violates this assumption by returning a handle next free (not first) it also breaks. Since our libc must be tolerant of anything that resembles DOS, it's a better thing to be defensive. > > Actually I've patched both in testing (freopen only does it's thing if > > the handle changes). But the _creat adds yet two more interrupts to > > already ugly code. (open, close, dup, close) vs just (close,open) or > > (open,close - with no guarantee of handle order). > > Isn't this the same overhead as in the fix for freopen? Yes, but freopen is called about 1/100th as much as _creat, and only executes the extra code if they are returned different. So it's a no operation on almost all setups (only acts on _creat handles or freedos weirdness). > > But do we need to fix _creat at all, since fixing the bug in freopen is > > more general, lower overhead? Are there other broken pieces of code that > > assume the handle will stay put? (that work with open directly?) > > If you can remember the example from freedos ? > > The example where the FreeDOS problem was reported had to do with > redirection. Normally, you redirect with the dup/open/dup2/close > series. In that case, some code did dup/close/open instead, and > expected to get the same handle from open as the one closed by the > preceding close. > > I don't remember what code was that, but it was from djlsr IIRC. I > will try to search mail archives on DJ's server. This still makes me really nervous. Pointing to bad code and screaming "BUG!" doesn't make anyone happier when it runs on Win9x and DOS but not on Win2K or XP. If I'm trying to fix these things, and they are more common than a single example, we probably need to change _creat to provide typical behavior to avoid triggering latent bugs. Sigh.