bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: getting EBADF on MSVC


From: Bruno Haible
Subject: Re: getting EBADF on MSVC
Date: Sat, 24 Sep 2011 12:38:24 +0200
User-agent: KMail/1.13.6 (Linux/2.6.37.6-0.5-desktop; KDE/4.6.0; x86_64; ; )

Hi Paul,

Paul Eggert wrote:
> > Gnulib uses the "all workarounds for function foo() in file foo.c" approach
> > since the beginning, and has been working very well with that.
> 
> I think this can work, but still, we should make it easy for
> non-Windows programmers to see which part of foo.c is for Windows,
> so that they can easily and safely ignore the Windows-related stuff.

But while doing so, we shouldn't throw the Autoconf principle overboard.
This means, we have to exerce judgement about which bugs can possibly occur
on other platforms as well, and let the fixes of Windows platforms also
benefit the Unix platforms, without code duplication.

> >> Emacs doesn't need to have a dummy msvc-inval.h file. ...
> > you can create a replacement for this file in a single-line Makefile 
> > statement.
> 
> One line would not be enough; the dummy file would need to be cleaned,
> and there may well have to be some other stuff due to the way Emacs is
> packaged.  I'd rather not have to think about that

I'd really like if you could think about that. It would take away from gnulib
pressure to accommodate hacks that are for Emacs only.

> There is plenty of precedent for putting Windows-only #includes inside
> appropriate #if, and there's plenty of precedent for putting
> gnulib-private #includes inside appropriate #ifs.  Here, there's a
> known and immediate technical win to putting the #include inside an
> #if (as this simplifies Emacs), whereas any technical loss is only
> hypothetical.  This is an easy call.
>
> +     sigprocmask: move #include directive

If such a micro-optimizations is harmless, it is fine with me. But here, and
in dup2.c, moving the #include directive past the "#undef signal" increases
the risk that future commits will introduce an endless recursion. It is
important that the "#undef signal" statement comes after *all* header files
have been included. Only this guarantees that there won't be another
"#define signal ..." enabled that we aren't aware of.


2011-09-24  Bruno Haible  <address@hidden>

        sigprocmask: Make code safer.
        * lib/sigprocmask.c: Move '#include "msvc-inval.h"' before the code
        section that changes macro definitions for this compilation unit.

--- lib/sigprocmask.c.orig      Sat Sep 24 12:37:00 2011
+++ lib/sigprocmask.c   Sat Sep 24 12:13:52 2011
@@ -24,6 +24,10 @@
 #include <stdint.h>
 #include <stdlib.h>
 
+#if HAVE_MSVC_INVALID_PARAMETER_HANDLER
+# include "msvc-inval.h"
+#endif
+
 /* We assume that a platform without POSIX signal blocking functions
    also does not have the POSIX sigaction() function, only the
    signal() function.  We also assume signal() has SysV semantics,
@@ -59,8 +63,6 @@
 typedef void (*handler_t) (int);
 
 #if HAVE_MSVC_INVALID_PARAMETER_HANDLER
-# include "msvc-inval.h"
-
 static inline handler_t
 signal_nothrow (int sig, handler_t handler)
 {

-- 
In memoriam Sara Harpman 
<http://www.genealogieonline.nl/en/stamboom-harpman/I399.php>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]