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

[Trent Mick]

On Tue, Jun 06, 2000 at 05:21:38PM -0400, Tim Peters wrote:
> [GregS]
> > ...
> > #  define SAFE_DOWNCAST(v) ((v) <= INT_MAX ? (int)(v) : abort())
> 
> [Trent Mick]
> > Sure, but then my compiler will still generate a warning on the
> > int downcast that you have there, hence still filling the compile
> > output with junk.
> 
> Will it really?  Greg has no *implicit* downcasts in that code, and I'm
> skeptical that your compiler generates a warning on *explicit* downcasts
> (the Win32 MS compiler certainly doesn't).  That would be very unusual.
> 

my test code (_testmodule.c):


--------------------------------------------
#define SAFE_DOWNCAST(v) ((v) <= INT_MAX ? (int)(v) : abort(),0)


PyObject*
some_function(PyObject *self, PyObject *args)
{
	size_t hello = 1234;
	int ihello = SAFE_DOWNCAST(hello);
}
-------------------------------------
			
Compiler output:
	
-------------------------------------
"c:\ia64xdevsdk\bin\Intel64\ecl.exe"  -nologo -W3 -GX -Fp".\ia64-temp-re lease\_test\_test.pch" -YX -Zi -Fd".\ia64-temp-release\_test\\" -Fo".\ia64-temp- release\_test\\" -DWIN32 -Wp64 -Ap64 -DWIN64 -D_WIN64 -FD -c  -Od -MD -DNDEBUG -Ic:\ia64xdevsdk\include -Ic:\ia64xdevsdk\include\sys -Ic:\ia64xdevsdk\include\g l -Ic:\ia64xdevsdk\include\mfc -Ic:\ia64xdevsdk\include\atl\include -DDEBUGGING -I"..\Include" -I"..\PC"  -I"C:\Program Files\Tcl\include" -D_WINDOWS ..\Module s\_testmodule.c
_testmodule.c
..\Modules\_testmodule.c(30) : warning #810: conversion from "unsigned __int64" to "int" may lose significant bits
        int ihello = SAFE_DOWNCAST(hello);
-------------------------------------
                     ^

ANswer: Yes it *still* complains about the explicit downcast. You think it
should not? I don't know if it should. Ideally I should be able to pick and
choose my classes of warnings.


> Your original example was
> 
> >       int size = sizeof(Py_UNICODE);
> 
> and changing PyObject_VAR_HEAD will have no effect on that (i.e., that
> warning will never go away until that specific line of code is changed).

Yes, I am mixing examples. The one above was fabricated but and is usually
tied, later in the code, to a Python string which really is the ob_size issue
that I mentioned.

> 
> > Yes, I presume that there is a "right" answer to fix most of
> > these warnings.  It is just that the "right" answer is going to
> > have to wait for a little bit.
> 
> It doesn't "have to".  Python *may* decide to limit sizes to int-sized
> things forever (there's not much *practical* need to expand ob_size -- it
> would just be "nice" to do so), and so long as it does the code is screwed
> up the way it is now.
> 
I can't argue with that. Although the change would be practical for *me*
given the work I have been doing. :) And it *would* be practical, in a sense,
for developpers if it cleaned up a bunch of warnings and/or code with
SAFE_DOWNCAST macros all over the place. 


> > Until then the Win64 build is going to have gobs of downcast warnings.
> 
> Which is bad.  You didn't create the problem, and nobody is going to force
> you to fix it.  Let's just agree that it *is* "a problem".  Then we can make
> progress.
> 
Yes, I agree it *is* a problem.



Trent
-- 
Trent Mick
trentm@activestate.com