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