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>
