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

[Trent Mick]

On Tue, Jun 06, 2000 at 03:09:19PM -0400, Tim Peters wrote:
> [Tim, rants about warnings]
> 
> [Trent Mick]
> > <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.
> 
> And all of those you decided to ignore will appear forever more in the Win64
> build, and everyone who comes after you (including you, 3 months from now
> <0.5 wink>) will see them every time they build, so no later than the 3rd
> build will stop looking at warnings entirely, and after that new and
> dangerous warnings in new or changed code will simply get overlooked along
> with the masses of old warnings.  That's fine for a project that never
> leaves your machine, but, sorry, it's simply exceedingly bad practice for
> group maintainability.

The problem is that I don't know *how* to properly express to the compiler
that this is not a problem. My hope (I acknowledge that it is a hope and not
a guarantee) is that those warnings will be cleaned up when I or someelse
know how to express this to the compiler.

> 
> > These were mostly warnings of downcasts, for example
> >
> > 	int size = sizeof(Py_UNICODE);
> >
> > Which is *not* going to overflow but still generates a warning.
> 
> The "proper" fix here is to change the decl to size_t.

Yes, you are right, but...

> If keeping the decl
> "int" is important, then the warning is thoroughly appropriate!  Casting
> sizeof's result to int is a bad but expedient wormaround.  Defining a
> SAFE_DOWNCAST macro (that checks that the downcast doesn't lose info in
> DEBUG mode, and does the downcast without checking in non-DEBUG mode) is a
> better (but still sucky) wormaround.  C is simply a pain in the ass here.
> 

*Is* there a way to express that the downcast is safe that is not sucky?


Trent

-- 
Trent Mick
trentm@activestate.com