emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Buffer size limitation in insdel.c


From: Lars Magne Ingebrigtsen
Subject: Re: Buffer size limitation in insdel.c
Date: Thu, 23 Sep 2010 15:37:35 +0200
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

Eli Zaretskii <address@hidden> writes:

>> dispnew.c:783: warning: conversion to 'int' from 'Lisp_Object' may alter its 
>> value
>> 
>>       matrix->window_left_col = WINDOW_LEFT_EDGE_COL (w);
>> 
>> What's the right fix here?  make window_left_col EMACS_INT, and slap an
>> XINT around the WINDOW_LEFT_EDGE_COL?
>
> I don't see this warning with "gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)".

This is with "gcc (Debian 4.4.4-7) 4.4.4".  When I was Googling for
-Wconversion, I found somebody saying that it's a switch that has
existed for a long time, but it was recently given a total makeover, and
was made to be more useful.

> And I don't see how you could possibly get it, since
> window_left_edge_col is an int, whereas WINDOW_LEFT_EDGE_COL is
> defined like this:
>
>     #define WINDOW_LEFT_EDGE_COL(W) \
>       (XFASTINT ((W)->left_col))
>
> So it already extracts the integer from a Lisp_Object.  What am I
> missing?

Hm.  What version of XFASTINT is being used by default?  If it's this
one, I can perhaps understand the warning.  I think.  

#define XFASTINT(a) ((a) + 0)

So gcc 4.4.4 doesn't understand that this converts from Lisp_Object a to
EMACS_INT a?  Which is what I'm assuming it's doing, although I'm not
sure whether the C standard actually allows doing it this way?

-- 
(domestic pets only, the antidote for overdose, milk.)
  address@hidden * Lars Magne Ingebrigtsen




reply via email to

[Prev in Thread] Current Thread [Next in Thread]