Re: bookkeeping to prepare for a 64-bit EMACS_INT on 32-bit hosts

[Stefan Monnier <monnier@iro.umontreal.ca>]

>>>>> >>> > -      /* The EMACS_INT cast avoids a warning. */
>>>>> >>> > +      EMACS_INTPTR ii = i;
>>>>> >>> > +      gpointer gi = (gpointer) ii;
>>>> >> Is there a particular reason why you use an intermediate var rather
>>>> >> than use the more concise "(gpointer) (EMACS_INTPTR) i"?
>>> > To avoid a cast.
>> I'm not sure what is the formal definition of "cast" in C, but at least
>> from my point of view, your code performs just the same kind of coercion
>> as a cast.

> The runtime behavior is the same, but avoiding the cast can catch more
> errors.  Suppose "i" is of type "struct tm *", say, and the programmer
> made a mistake.  Then GCC will issue a helpful diagnostic for the form
> with just one cast, but it won't diagnose the more-concise form with
> two casts.

Right, implicit coercions are indeed checked more thoroughly since the
programmer doesn't say explicitly to shut up.

My favorite choice would be to force all casts to have a more easily to
find shape (e.g. so `grep' can find them) and to split them into various
categories, so the above EMACS_INTPTR cast would be labeled as
"checked" or "safe", so the compiler can output warnings.

>>> > If you prefer conciseness to avoiding these casts, I can easily change
>>> > these to the more-concise form.
>> I do prefer the more concise form, and paradoxically part of the reason
>> is because it is uses a explicit coercion rather than an implicit one.
> OK, will do (unless the above argument convinced you :-).

Given that

  #define checked_cast(t,x) ({ t v = (x); v})

can't be written in ISO C (AFAIK), I either form will be suboptimal,
so there's no need to change the code.


        Stefan