[Top][All Lists]

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

Re: composition bug

From: Kenichi Handa
Subject: Re: composition bug
Date: Thu, 18 Sep 2008 10:23:23 +0900
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/23.0.60 (i686-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

In article <address@hidden>, Romain Francoise <address@hidden> writes:

> Kenichi Handa <address@hidden> writes:
> > (gdb) br composite.c:1432

> Thanks, I should have started there because the problem was
> immediately obvious when in gdb: an EMACS_INT arg was being
> given the literal -1, which is int.  On my machine (amd64),
> EMACS_INT is long and due to the traditional function prototype
> the value isn't casted automatically.  I installed a fix.

Ah!!! Thank you for fixing it.

> By the way, it looks like the functions in this file use int for
> buffer positions in many places, there could be other bugs like this
> one.  Building with `-Wtraditional-conversion' on amd64 finds quite
> a few occurrences of width mismatch.

I'm always confused by int and EMACS_INT.  "struct it" and
"struct text_pos" in dispextern.h uses "int" for
buffer/string positions, and xdisp.c calls functions in
composite.c with those values.  So, there exist mixture of
int and EMACS_INT.  Shouldn't all of them use EMACS_INT for
positions (and perhaps for string length)?

Kenichi Handa

reply via email to

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