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

Tim Peters tim_one@email.msn.com
Mon, 5 Jun 2000 22:49:36 -0400

[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.

> 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.  But
in any case, "no warnings!" is an excellent rule.