Compiling with Intel's icc I get lots of remarks like this:

    icc -c -fno-strict-aliasing -DNDEBUG -g  -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I../Include   -DPy_BUILD_CORE -o Parser/acceler.o ../Parser/acceler.c
    ../Include/longobject.h(35): remark #193: zero used for undefined preprocessing identifier "SIZEOF_SOCKET_T"
      #if SIZEOF_SOCKET_T <= SIZEOF_LONG
          ^

This is only defined in Modules/socketmodule.h.  It should probably be
defined somewhere else if it's to be referenced by longobject.h.

Skip

I'm seeing this with gcc-4.4.3 with -Wall -Werror, leading to fatal errors trying to build an extension module against python 3.1

The references to SIZEOF_SOCKET_T within longobject.h appear to be just in the py3k branch, not trunk, and were added in r59009.  I'm marking this issue as python3, and as both "Interpreter Core" and "Extension Modules".

There didn't seem to be a natural place to put these types, so I'm attaching a patch against the py3k branch which adds a new public/installed header file: Include/socketrepr.h, specifically to contain them.   How does this look?

> I'm seeing this with gcc-4.4.3 with -Wall -Werror, leading to fatal errors
> trying to build an extension module against python 3.1

Specifically, with gcc, I'm seeing this warning (trying to port SELinux Python support to Python3), which, with -Werror becomes fatal:
In file included from /usr/include/python3.1/Python.h:72,
                 from audit2why.c:1:
/usr/include/python3.1/longobject.h:36:5: error: "SIZEOF_SOCKET_T" is not defined
cc1: warnings being treated as errors

We don't need a separate header file, the definitions can go into pyport.h instead.

However, since this makes SOCKET_T public, it should probably be renamed to Py_SOCKET_T.

After trying it out, pulling SOCKET in the Python headers brings complications under Windows, because you need to include <winsock2.h> which in turn breaks compilation of _pickle.c (duplicate definition of "FLOAT", "INT", etc.).

An alternative approach would be to define only SIZEOF_SOCKET_T in the standard headers (we don't actually need access to the SOCKET type to compute it, as the current hard-coding shows), and leave SOCKET_T in socketmodule.h.

Here is a patch implementing the approach I proposed above.
It successfully removes warnings about casting SOCKET to long under 64-bit Windows.

sockdefine.patch seems fine to me.

Why is PyLong_FromSocket_t defined in a header file in the first place? The only caller is in socketmodule.c, and calling it elsewhere wouldn't work, anyway, since it relies on SOCKET_T being defined.

So -1 on the patch.

> Why is PyLong_FromSocket_t defined in a header file in the first
> place? The only caller is in socketmodule.c, and calling it elsewhere
> wouldn't work, anyway, since it relies on SOCKET_T being defined.

I agree, but it was already like that, and I didn't want to change it.

> I agree, but it was already like that, and I didn't want to change it.

This goes back to issue 1378. Christian, do you recall why you needed to add the helper macros to a header file? You said

# Added PyLong_FromSocket_t and PyLong_AsSocket_t to longobject.h 
# to get rid of some 64bit warnings

but I doubt that it really needed to live in the header file.

This new patch takes the reverse approach and makes the function definitions (PyLong_FromSocket_t() and PyLong_AsSocket_t()) private to socketmodule.h. I will commit if no-one objects.

Committed in r84347 (py3k) and r84348 (3.1).