Horton

Thread

Commits

  1. Define _WINSOCK_DEPRECATED_NO_WARNINGS in all MSVC builds.

  1. _WINSOCK_DEPRECATED_NO_WARNINGS

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-11-16T16:37:05Z

    Checking the buildfarm to see if ed9b3606d broke anything, I notice
that woodlouse is producing stacks of warnings like this:

src/port/thread.c(134): warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW() instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated API warnings [C:\buildfarm\buildenv\HEAD\pgsql.build\libpgport.vcxproj]
          C:\Program Files (x86)\Windows Kits\8.1\Include\um\winsock2.h(2238) : see declaration of 'gethostbyname'

and was doing so before that commit, so it's not my fault :-)

win32.h has

 * Also for VS2015, add a define that stops compiler complaints about
 * using the old Winsock API.
 */
#if defined(_MSC_VER) && _MSC_VER >= 1900
#define  _WINSOCK_DEPRECATED_NO_WARNINGS

but evidently it chose the wrong cutoff for when to enable that
symbol, because woodlouse is (or claims to be) running VS2013.

Is there any good reason not to just define
_WINSOCK_DEPRECATED_NO_WARNINGS unconditionally?  Presumably
it would have no effect on VS versions too old to know the symbol.

I'm a bit inclined to move it to win32_port.h, as well,
since that's what includes <winsock2.h>.

			regards, tom lane

  2. Re: _WINSOCK_DEPRECATED_NO_WARNINGS

    Glen Knowles <gknowles@ieee.org> — 2017-11-17T03:28:19Z

    On Thu, Nov 16, 2017 at 8:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>  * Also for VS2015, add a define that stops compiler complaints about
>  * using the old Winsock API.
>  */
> #if defined(_MSC_VER) && _MSC_VER >= 1900
> #define  _WINSOCK_DEPRECATED_NO_WARNINGS
>
> but evidently it chose the wrong cutoff for when to enable that
> symbol, because woodlouse is (or claims to be) running VS2013.
>
>
It's actually checking the wrong thing, the problem is the version of the
Windows SDK, and while the one installed by default with VS2015 might be
the right place to cutoff it's not uncommon to have multiple versions of
the SDK (and VS) in various combinations.

To check against the SDK you'd need something like:
#include <ntverp.h>
#if VER_PRODUCTBUILD >= 8100
#define _WINSOCK_DEPRECATED_NO_WARNINGS
#endif


> Is there any good reason not to just define
> _WINSOCK_DEPRECATED_NO_WARNINGS unconditionally?  Presumably
> it would have no effect on VS versions too old to know the symbol.
>

Or you could just define it unconditionally. :)

  3. Re: _WINSOCK_DEPRECATED_NO_WARNINGS

    Tom Lane <tgl@sss.pgh.pa.us> — 2017-11-17T03:46:55Z

    Glen Knowles <gknowles@ieee.org> writes:
> On Thu, Nov 16, 2017 at 8:37 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> but evidently it chose the wrong cutoff for when to enable that
>> symbol, because woodlouse is (or claims to be) running VS2013.

> It's actually checking the wrong thing, the problem is the version of the
> Windows SDK, and while the one installed by default with VS2015 might be
> the right place to cutoff it's not uncommon to have multiple versions of
> the SDK (and VS) in various combinations.

Ah, interesting point --- though it's not clear that woodlouse is actually
running a mixture of SDK/VS releases.

> Or you could just define it unconditionally. :)

Already done that way.

I wonder though if this means the other tests of _MSC_VER in our tree
are wrong?

			regards, tom lane