Re: Emacs-diffs Digest, Vol 94, Issue 89

[Lars Magne Ingebrigtsen <larsi@gnus.org>]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> -  int frame_lines = FRAME_LINES (frame);
>> >> +  EMACS_INT frame_lines = FRAME_LINES (frame);

[...]

> So what is the practical guidance to Lars and others who go by the
> warnings emitted by -Wconversion?  Will the below be okay, for when an
> small-valued EMACS_INT is assigned to an int:
>
>  . if the source is EMACS_INT, consider making it an int; if that's
>    not possible, cast to int, preferably inside a macro
>
>  . if the source is a Lisp_Object passed through XINT, cast to an int,
>    preferably inside an accessor macro

So in this case FRAME_LINES should cast to an int before returning?
Makes sense to me, and I can redo the stuff in that file based on that. 

Or just make these into ints:

  /* Size of this frame, excluding fringes, scroll bars etc.,
     in units of canonical characters.  */
  EMACS_INT text_lines, text_cols;

It does seem rather nonsensical to have them be EMACS_INT...

Which reminds me about a question about characters.  Can they really be
longs?  Let's see...

DEFUN ("char-resolve-modifiers", Fchar_resolve_modifiers,
...
  (Lisp_Object character)
{
  int c;

  CHECK_NUMBER (character);
  c = XINT (character);
  return make_number (char_resolve_modifier_mask (c));
}

Hm.  In that case it should perhaps actually be EMACS_INT, since the
character comes from "user space".  So that's a bad example.  :-)  But
the general question is whether characters can be longs still stand, and
whether there then should be like an XCHAR macro that does the same as
XINT, but casts to int.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen