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

Greg Stein gstein@lyra.org
Mon, 5 Jun 2000 20:22:13 -0700 (PDT)


On Mon, 5 Jun 2000, Tim Peters wrote:
>...
> 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.

Agreed, and I also support the notion of extended checks and
"die-on-warning" flags. Heck... I just ran "lint" over mod_dav the other
day. Hehe...

[ check out "lclint"; found via Freshmeat ]

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

Yes, this was it, and moving to ANSI decls will help in a lot of cases.

My issue was mostly based around seeing a *cast*. IMO, the presence of a
cast means that something else is wrong. The cast is going to hide *that*,
which can be even worse than trying to get a warning-free compile.

In this case, the cast was hiding the K&R declaration.

A month or so ago, I was pointing out problems with some casts in a patch
to the new mmapmodule.c. Sure enough, the variables were just declared
improperly.

Removing warnings: Goodness. Using casts: (typically) Badness.

Cheers,
-g

p.s. casts are best used to create a more specific type (PyStringObject*)
from a (PyObject*), or (whatever*) from a (void*).

-- 
Greg Stein, http://www.lyra.org/