emacs-devel
[Top][All Lists]
Advanced

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

Re: Intervals crash


From: Eli Zaretskii
Subject: Re: Intervals crash
Date: Fri, 24 Sep 2010 10:16:01 +0200

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Chong Yidong <address@hidden>,
>     address@hidden
> Date: Fri, 24 Sep 2010 15:12:34 +0900
> 
>  > I'd rather fix it properly.  I replaced all EMACS_UINT with
>  > EMACS_INT in intervals.c, it couldn't be worse than int it used
>  > before.
> 
> You should just do that everywhere.  EMACS_UINT is a bad idea, and
> should be avoided.

Easier said then done, for someone such as myself, with very limited
resources.  I used EMACS_UINT because the related data structure used
it for some of its members.  I didn't have time to study the code
enough to understand whether it was really needed, but the change
which introduced it was deliberate, so I trusted that whoever did it
had good reasons.

> First, unsigned-ness tends to propagate because of C coercion rules,
> which is rarely desired

Funny that you should mention it, because I used EMACS_UINT precisely
to avoid such problems (comparison of signed and unsigned), given that
some struct members were unsigned.

> The conclusion is that unsigneds (eg, size_t's) should be treated the
> same way you treat legacy-encoded external text input: hazardous
> material that you should convert to some sane internal type as soon as
> possible, and to be produced only just before use in external APIs.
> As such, there's really no need for EMACS_UINT.

If you really need the full range of size_t or EMACS_UINT, there's
little you can do in practice.



reply via email to

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