Mail Archives: djgpp-workers/2001/06/18/02:53:10
On Sun, 17 Jun 2001, Tim Van Holder wrote:
> > _fwalk walks all
> > the FILE objects and fflushes them before closing, not just closes the
> > handle.
>
> Will look into it. This would not catch files opened with regular open()
> though, would it?
No. For those, you will need the loop you posted.
But I don't really understand what problem is this close-all code
supposed to solve? Could you elaborate on what does lclint do that
forces you to use such techniques?
> And are stdin/stdout/stderr part of the list of
> FILE*s walked by _fwalk?
It fflushes them, but doesn't close them. Which might be not what you
want if the file in question has one of the standard streams
redirected to it.
> +@subheading Caveat
> +
> +The @sc{posix} specification requires this removal to be delayed until the
> +file is no longer open. Due to problems with the underlying operating
> +systems, this implementation of @code{unlink} does not fully comply with
> +the specs; if the file you want to unlink is open, you're asking for
> +trouble - how much trouble depends on the underlying OS. On NT (and
> +possibly on 2000 as well), you get the behaviour @sc{posix} expects.
> +On Win9x and WinME (and possibly WinXP as well), the removal will simply
> +fail (@code{errno} gets set to @code{EACCES}). On DOS, removing an
> +open file could lead to filesystem corruption if the removed file is
> +written to before it's closed.
This is okay, but:
- please replace a single "-" with "---", this will make makeinfo and
TeX produce a dash;
- please say "Windows 2000", for more clarity; and
- we don't like to think about Windows as ``a win'', so please change
WinFOO into Windows FOO.
Other than that, this can go in. Thanks!
- Raw text -