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