delorie.com/archives/browse.cgi | search |
From: | "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be> |
To: | <djgpp-workers AT delorie DOT com> |
Subject: | Re: Our unlink() isn't POSIX |
Date: | Mon, 18 Jun 2001 18:51:15 +0200 |
Message-ID: | <CAEGKOHJKAAFPKOCLHDIAEGLCEAA.tim.van.holder@pandora.be> |
MIME-Version: | 1.0 |
X-Priority: | 3 (Normal) |
X-MSMail-Priority: | Normal |
X-Mailer: | Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) |
In-Reply-To: | <Pine.SUN.3.91.1010618132911.24334E@is> |
X-MimeOLE: | Produced By Microsoft MimeOLE V5.50.4133.2400 |
Importance: | Normal |
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 |
> > It keeps a table of files it has opened; this table has an associated > > cleanup function that unlinks those that need to be removed. But it > > never seems to close those files (or not all of them anyway), resulting > > in an error in unlink() (on LoseME anyway). > > I've now simply added a call to the stdio_cleanup_proc in those places > > where an _fcloseall() was added on Lose32. > > Isn't it cleaner to close each file just before it is unlinked? > Yes - but the file table keeps only names, not FILE*s/fds. In order to do the clean thing, I'd have to introduce a new field in that table, and I'm loath to do this (for example, if I keep a FILE* there, what happens if it is fclose()'d later? The cleanup function would try to fclose() an already closed/deallocated FILE*. I agree it's not the cleanest fix, but it's the best I could without making major modifications to the source.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |