[Top][All Lists]

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

Re: new module 'isatty'

From: Eli Zaretskii
Subject: Re: new module 'isatty'
Date: Tue, 03 Jan 2012 08:48:04 -0500

> From: Bruno Haible <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden, address@hidden, 
> address@hidden
> Date: Tue, 03 Jan 2012 14:03:11 +0100
> Eli Zaretskii wrote:
> > >       HANDLE h = (HANDLE) _get_osfhandle (fd);
> > 
> > Why not use intptr_t instead of HANDLE
> Because the common way to write code for the Windows API is to use the
> Windows types, not the ISO C 89 types.

But the MS headers and MSDN explicitly document _get_osfhandle return
type as intptr_t.  I guess its finally 89 in Redmond as well ;-)

> > and get rid of the cast, both
> > here and in IsConsoleHandle above?
> Because that would yield warnings when you compile on mingw with "-Wall".

I compiled with -Wall (using intptr_t) and didn't have any warnings.
Maybe you are using a newer (= more pedantic) version of GCC.

> > Also, I'd replace "NUL device" with a more accurate
> > "all character devices such as the null device", similar to what you
> > wrote in the manual.
> Well, I tested also aux, com, com1, lpt, lpt1, prn, and none of these
> resulted in a successful open() call. Only nul and con could be open()ed,
> and only for nul was the value of _isatty() wrong. Tested on Windows XP
> (with no printer connected). YMMV.

You don't need to open them, you can use redirection:

  _isatty < nul > prn 2>aux

I tested this on XP, and I see the value 64 returned by _isatty for
every character device.

Btw, it also works for me to open them, but I tried `fopen', not

> Thanks all for your comments. I'm applying this additional patch,
>   - to fix a test failure on MSVC 9,
>   - to fix the two wrong comments.


reply via email to

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