[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
> > -DDEBUGGING -I"..\Include" -I"..\PC" -DUSE_DL_EXPORT -D_WINDOWS
> > ..\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
example
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
--
Trent Mick
trentm@activestate.com