Re: getting EBADF on MSVC

[Paul Eggert]

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.  We should separate the
Windows concerns from the mainstream code, as much as possible, even
if that makes the code a bit more cluttered for Windows developers.

For example, it's not reasonable to replace code like this:

  return dup2 (a, b);

with code like this:

  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...".  Arrggh!

We need something better.