Re: getting EBADF on MSVC

[Bruno Haible]

Paul Eggert wrote:
> On 09/19/11 14:37, Bruno Haible wrote:
> > Is this code (with a #if and two extra functions) really easier to 
> > understand
> > than what we have in lib/dup2.c now?
> 
> I find it easier to understand, because I can safely ignore
> the stuff that's inside the "#if MSVC ..." brackets.
> 
> On 09/19/11 14:15, Bruno Haible wrote:
> > I don't see why a lack of MSVC knowledge would prevent anyone from modifying
> > these files. The code structure and intent are clear enough.
> 
> They may be clear to someone who understands MSVC and its exception
> handling principles, but they are not clear to people who don't
> understand them, and the rest of us should not have to understand
> them.  It's OK to add support for MSVC, but it's not OK for this
> support to pose a significant burden on GNU and GNUish platforms.
> 
> I'm not objecting to this MSVC stuff if it's put inside areas that are
> "#ifdef _WIN32" or are otherwise clearly marked so that they are for
> Windows only, and which the rest of us can safely ignore.  But the
> style used in dup2.c is cluttering code that is otherwise perfectly
> clear on mainstream (non-Windows) platforms.

That's a valid point. I'll restructure the code like this:

#include "msvc-inval.h"
...
#if HAVE_MSVC_INVALID_PARAMETER_HANDLER
static inline int
dup2_nothrow (int fd, int desired_fd)
{
  int result;

  TRY_MSVC_INVAL
    {
      result = dup2 (fd, desired_fd);
    }
  CATCH_MSVC_INVAL
    {
      result = -1;
      errno = EBADF;
    }
  DONE_MSVC_INVAL;

  return result;
}
#else
# define dup2_nothrow dup2
#endif

int
rpl_dup2 ...
{
...
  result = dup2_nothrow (fd, desired_fd);
...
}

>   TRY_MSVC_INVAL
>     {
>       return dup2 (a, b);
>     }
>   CATCH_MSVC_INVAL
>     {
>       errno = EBADF;
>       return -1;
>     }
>   DONE_MSVC_INVAL
> 
> Oh, but wait a minute, that MSVC replacement doesn't work, because one
> is not allowed to do a "return" inside a "TRY...".

Yes, that's documented in msvc-inval.h.

> We need something better.

The "something better" is a language with automatic cleanups, that is, C++.
But we don't want that, because it drags in a can of other problems (from
'const'ness problems to linking requirements).

Bruno
-- 
In memoriam Pierre Goldman <http://en.wikipedia.org/wiki/Pierre_Goldman>