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

Tim Peters tim_one@email.msn.com
Tue, 6 Jun 2000 17:00:36 -0400


[Trent Mick]
> ...
> The problem is that I don't know *how* to properly express to the compiler
> that this is not a problem.

Yes you do <wink>:  change the code so that size_t-valued expressions only
get assigned to size_t-declared lvalues.  Anything short of that is
potentially unsafe (that's why the compiler is warning!), and, like I said,
C is a pain in the ass here.

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

Really not that I know of.  You can do some nice tricks with templates in
C++, but I know of no reasonable way to write portable code in C that
doesn't involve a layer of typedefs and macros.  I have to spend the next 4
hours packing boxes, but Greg was on to the flavor of a workable idea.  The
"is the downcast safe?" test is better expressed not relying on limits.h,
like

/* DEBUG branch only here */
#define SAFE_DOWNCAST(EXPR, INT_TYPE) \
    (INT_TYPE)(EXPR) == (EXPR) ? \
    (INT_TYPE)(EXPR) : \
    complainBitterly(yadda, yadda, yadda)

This is prone to all the problems that come with C's macros, but so it goes.
An alternative:

/* DEBUG branch only here */
#define SAFE_DOWNCAST(EXPR, INT_TYPE) \
    downcaster_ ## INT_TYPE ((WIDEST_INT_TYPE)(EXPR), \
                             filename and linenumber, etc)

That is, use the token-pasting operator to synthesize the name of a
type-specific downcasting function.  Then EXPR gets evaluated only once, and
at least there's a function name to stick a debugger hook on.  All in all,
better to avoid the need for downcasting at the root!