Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!pasteur!ames!killer!jls
From: jls@killer.Dallas.TX.US (Jerome Schneider)
Newsgroups: comp.lang.c
Subject: Re: Bug in MS C unlink() ?
Summary: unlink() at exit
Message-ID: <7560@killer.Dallas.TX.US>
Date: 16 Mar 89 08:26:06 GMT
References: <89Mar13.100742est.10755@ephemeral.ai.toronto.edu> <1205@naucse.UUCP> <9849@smoke.BRL.MIL>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 15

In article <9849@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn ) writes:
> In article <1205@naucse.UUCP> jdc@naucse.UUCP (John Campbell) writes:
> >Oh well, I just followed up to suggest that MSC and PC implementors shouldn't
> >provide an unlink() that is not compatible with the unix counter part.  ...
> >.....

MSC 5.x provides the atexit() mechanism for stashing up to 32 function 
pointers to be called at exit (and _exit).  This would seem the likely
spot to process any unlinks() from open file handles.  Agreed, it does
not address the question of what I/O to an unlinked but open file really
means. 

-- 
Jerome Schneider              UUCP: killer!jls.DALLAS.TX.US (guest account)
Aspen Technology Group        Ft. Collins, CO    Voice: (303) 484-8466