On Thu, Apr 14, 2011 at 7:07 PM, Sean McNamara <smcnam at gmail.com> wrote: > Hi, > > On Thu, Apr 14, 2011 at 9:57 AM, Daniel Mack <zonque at gmail.com> wrote: >> On Thu, Apr 14, 2011 at 3:53 PM, Maarten Bosmans <mkbosmans at gmail.com> wrote: >>> 2011/4/14 Daniel Mack <zonque at gmail.com>: >>>> On Thu, Apr 14, 2011 at 12:46 AM, Maarten Bosmans <mkbosmans at gmail.com> wrote: >>>>> return (fd >= 0) && (fcntl(fd, F_GETFL) != -1); >>>>> >>>>> For Windows, both fcntl and F_GETFL are not available. >>>> >>>> Sigh. Ok, thanks for the feedback. Attached is a new patch which keeps >>>> things as they are for Windows but fixes the problem for OS X. >>> >>> That should do it, yes. >>> >>> +#else /* !OS_IS_WINDOWS */ >>> Minor: this is not exactly the symbol used in the #ifdef. >> >> Ok. >> >>> Anyway, isn't the #else only supposed to be used for OSX? In that case >>> the comment should probably say so. >> >> No, it's actually really a workaround for Windows as we don't have >> fcntl() there. (Just curious - the header file does exist, right? I >> saw it being included by quite a lot of other source files in the PA >> tree ...) > > The fcntl.h header *does* exist in MSVC (and in MingW...) but the core > Microsoft C Runtime doesn't actually export the fcntl function. On > Windows, fcntl header only exists to expose the O_* hexadecimal > #defines for the flags for the open() call, which *is* supported. > > The only fcntl on Windows comes if you use an alternative C library, > such as Cygwin's port of newlib or glibc. The native stack doesn't > supply it. Ok, thanks for expaining. Colin, can you pick the latest patch from this thread then and apply? Or do you want me to push it and send a pull request? Thanks, everone. Daniel