[Patches] fix simple 64-bit warnings/errors in signalmodule.c and bufferobject.c

Trent Mick trentm@activestate.com
Mon, 5 Jun 2000 20:07:29 -0700

On Mon, Jun 05, 2000 at 10:49:36PM -0400, Tim Peters wrote:
> [Trent Mick]
> > ...
> > Intel's Win64 compiler output:
> >
> >
> > "c:\ia64xdevsdk\bin\Intel64\ecl.exe"  -nologo -W3 -GX
> > -Fp".\ia64-temp-release\python16\python16.pch" -YX -Zi
> > -Fd".\ia64-temp-release\python16\\"
> > -Fo".\ia64-temp-release\python16\\" -DWIN32 -Wp64 -Ap64 -DWIN64
> > -D_WIN64 -FD -c  -Od -MD -DNDEBUG -Ic:\ia64xdevsdk\include
> > -Ic:\ia64xdevsdk\include\sys -Ic:\ia64xdevsdk\include\gl
> > -Ic:\ia64xdevsdk\include\mfc -Ic:\ia64xdevsdk\include\atl\include
> > ..\Objects\bufferobject.c
> > bufferobject.c
> > ..\Objects\bufferobject.c(169) : warning #180: argument is
> > incompatible with formal parameter
> >   	return _PyBuffer_FromMemory(NULL, ptr, size, 1);
> >   	                            ^
> >
> > Adding the cast to a PyObject* gets rid of the warning. Perhaps I am
> > overreacting to an innocuous warning?
> NO!  Not possible to overreact.  Python should compile warning-free on every
> platform it gets built on.  Sometimes that will require catering to crippled
> compilers, but tough luck.  The invariable alternative is that warnings get
> ignored, and the invariable outcome of that is that serious portability bugs
> go uncaught.  More, if I have anything to say about it (and I suspect I will
> before too long <wink>), the warning level will get cranked tighter on
> compiles, and "treat warnings as fatal errors" will get enabled.  This
> tedious infrastructure work pays off bigtime over time.

<duck>There are a whole schwack of warnings that I am ignoring on the Win64
build. Basically I went through every one and, through code analysis, decided
if it could be ignored or not. These were mostly warnings of downcasts, for

	int size = sizeof(Py_UNICODE);

Which is *not* going to overflow but still generates a warning.

> [GregS]
> > These casts should not be required. NULL is "all types" ... why the cast?
> It could be that the K&R-style declaration of _PyBuffer_FromMemory does not
> convince this compiler that _PyBuffer_FromMemory has an explicit prototype
> in scope at the point of call.  Trent could try playing with that too. i

Give the man a prize. That was it. We'll just forget that part of the
patch then and thank you Tim for changing all function declarations from K&R
to ANSI. :)


Trent Mick