Using isatty() on WIN32 platform
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t37755psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 28, 2026 at 02:13 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t37755_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t37755_1 && git checkout t37755_1Patchset v1 (message #1) is on t37755_1
Hi,
While following suggestions from Arthur Zakirov on a patch for
pg_basebackup I found that we are using isatty() in multiple places, but
we don't distinguish the WIN32 code which should use _isatty() as per [1]https://msdn.microsoft.com/en-us/library/ms235388.aspx.
It's true that isatty() is still supported by Visual C (else we'd fail
to compile) but per the documentation it could get removed at any moment.
Instead of just using #ifdef in my patch, I thought we could have a
cleaner patch which would cover all calls for isatty().
Attached is a patch for src/include/ports/win32.h
[1]: https://msdn.microsoft.com/en-us/library/ms235388.aspx
P.D.: Which would be the correct usage, per-standards: with or without
the _ prefix?
--
Mart�n Marqu�s http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
=?UTF-8?Q?Mart=c3=adn_Marqu=c3=a9s?= <martin@2ndquadrant.com> writes:
While following suggestions from Arthur Zakirov on a patch for
pg_basebackup I found that we are using isatty() in multiple places, but
we don't distinguish the WIN32 code which should use _isatty() as per [1].
I dunno, [1] looks like pure pedantry to me. Unless they intend to stop
conforming to POSIX at all, they aren't going to be able to remove the
isatty() spelling.
Moreover, I don't think that isatty() is the only function name at issue.
I found this at:
https://docs.microsoft.com/en-us/cpp/c-runtime-library/compatibility
The C++ standard reserves names that begin with an underscore in the
global namespace to the implementation. Because the POSIX functions
are in the global namespace, but are not part of the standard C
runtime library, the Microsoft-specific implementations of these
functions have a leading underscore. For portability, the UCRT also
supports the default names, but the Visual C++ compiler issues a
deprecation warning when code that uses them is compiled. Only the
default POSIX names are deprecated, not the functions. To suppress the
warning, define _CRT_NONSTDC_NO_WARNINGS before including any headers
in code that uses the original POSIX names.
If you're seeing warnings from use of isatty(), I'd be inclined to think
about dealing with it by adding #define _CRT_NONSTDC_NO_WARNINGS,
rather than trying to individually #define every affected function.
Attached is a patch for src/include/ports/win32.h
FWIW, if we do adopt that, I think it should now go into win32_port.h.
In either case, though, seems like it might be problematic to have
such a #define before including whatever file Microsoft's definition
lives in.
regards, tom lane
On 21 November 2017 at 03:53, Tom Lane <tgl@sss.pgh.pa.us> wrote:
=?UTF-8?Q?Mart=c3=adn_Marqu=c3=a9s?= <martin@2ndquadrant.com> writes:
While following suggestions from Arthur Zakirov on a patch for
pg_basebackup I found that we are using isatty() in multiple places, but
we don't distinguish the WIN32 code which should use _isatty() as per[1].
I dunno, [1] looks like pure pedantry to me. Unless they intend to stop
conforming to POSIX at all, they aren't going to be able to remove the
isatty() spelling.
I agree that it's meaningless pedantry, and we should just suppress any
warning and get on with our lives.
If you're seeing warnings from use of isatty(), I'd be inclined to think
about dealing with it by adding #define _CRT_NONSTDC_NO_WARNINGS,
rather than trying to individually #define every affected function.
Yes, this.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services