Hi,
normally closing a closed file descriptor is not a big deal, it just
returns EBADF and everybody goes on with their lives. In Visual Studio
8 it seems to throw up an assertion. I'm dealing with some code that
just goes through the file descriptor table and closes them all (pretty
typical thing to do in Unix world and OK thing to do on Windows...
until now). Would appreciate any ideas on how to change the behaviour
of close() to relax and not assert it. Is there any way to tell
whether fd is open (without digging into internal data structures of
CRT)?

On 6 Apr 2006 14:54:40 -0700, "mk" <meshko> wrote:

>Hi,
>normally closing a closed file descriptor is not a big deal, it just
>returns EBADF and everybody goes on with their lives. In Visual Studio
>8 it seems to throw up an assertion. I'm dealing with some code that
>just goes through the file descriptor table and closes them all (pretty
>typical thing to do in Unix world and OK thing to do on Windows...
>until now). Would appreciate any ideas on how to change the behaviour
>of close() to relax and not assert it. Is there any way to tell
>whether fd is open (without digging into internal data structures of
>CRT)?

Well, if you look into the CRT, you'll find the _close source does the
following:

if ( _osfile(fh) & FOPEN )

Unfortunately, neither _osfile nor FOPEN appear to be defined in the public
header files. But there may still be hope.

To suppress the assertion, see _CrtSetReportHook2 and the very important:

Report Hook Functions
http://msdn2.microsoft.com/en-us/lib...yx(VS.80).aspx

To fix the problem in release mode, read the new documentation for _close:

http://msdn2.microsoft.com/en-us/lib...ss(VS.80).aspx
<q>
This function validates its parameters. If fd is a bad file descriptor, the
invalid parameter handler is invoked, as described in Parameter Validation.
If execution is allowed to continue, the functions returns -1 and errno is
set to EBADF.
</q>

In particular, follow it to:

Parameter Validation
http://msdn2.microsoft.com/en-us/lib...44(VS.80).aspx

And finally use:

_set_invalid_parameter_handler
http://msdn2.microsoft.com/en-us/lib...zb(VS.80).aspx

These methods will work. Hopefully, someone will find a _closeall function
comparable to _fcloseall that I missed and save you all this trouble. Of
course, the best thing would be to fix the code so it doesn't need to
iterate the fds. (How do you know how big the Unix-style fd table is,
anyway?)

Thank you very much, very detailed. I was looking at that parameter
validation link from close() docs but something misfired in the brain
(happens a lot lately) and I didn't click it...

Of course it is better to fix it, but with a big project and tight
schedule I'd rather not touch some of the things...

On Unix there is a function getdtablesize() which gives you max number
of fds process can have. _closeall() exists on some platforms (I
beleive Solaris and some BSDs) but it is not standard and usually has
different names. Besides it's usually not closeall, but "close all
that are greater than n". Needed for fork() mostly. I suspect I don't
really need to do this closing on the Windows version, but thanks a lot
for your help!

On 6 Apr 2006 19:35:58 -0700, "mk" <meshko> wrote:

>Thank you very much, very detailed. I was looking at that parameter
>validation link from close() docs but something misfired in the brain
>(happens a lot lately) and I didn't click it...
>
>Of course it is better to fix it, but with a big project and tight
>schedule I'd rather not touch some of the things...
>
>On Unix there is a function getdtablesize() which gives you max number
>of fds process can have. _closeall() exists on some platforms (I
>beleive Solaris and some BSDs) but it is not standard and usually has
>different names. Besides it's usually not closeall, but "close all
>that are greater than n". Needed for fork() mostly. I suspect I don't
>really need to do this closing on the Windows version, but thanks a lot
>for your help!

You're welcome. Another approach would have been to try to allocate all
possible fds on the "NUL" device. Then if you didn't get the fd number you
were looking for, you could assume it was open. Not recommended at all. <g>