EMACS_INT to EMACS_UINT

EMACS_INT to EMACS_UINT

[Ravi Desai]

Hello all,

I've been trying to familiarize myself with the emacs source at the 
C-level, and while I was looking at src/lisp.h I noticed that while 'XLI 
(a)' should return an EMACS_INT, we expect it to be a EMACS_UINT in the 
definition of 'XTYPE'.

---
/* Extract A's type.  */
INLINE enum Lisp_Type
XTYPE (Lisp_Object a)
{
   EMACS_UINT i = XLI (a); // <---- This seems strange to me.
   return USE_LSB_TAG ? i & ~VALMASK : i >> VALBITS;
}
---

Is this something that we should change? The code is working, so I don't 
know if its a big enough deal.

Re: EMACS_INT to EMACS_UINT

[Paul Eggert]

On 12/04/2016 03:16 PM, Ravi Desai wrote:
> Is this something that we should change? The code is working

I'm not sure what you'd change. In many places the Emacs C code relies 
on the fact that unsigned arithmetic is modulo 2**N, where N is the 
width of the unsigned integer, so that (for example) converting -1 to 
unsigned yields UINT_MAX. XLI and XIL are intended for low-level use, 
where this part of C semantics is assumed to be well-understood.

Re: EMACS_INT to EMACS_UINT

[Ravi Desai]

On 2016-12-04 09:00 PM, Paul Eggert wrote:
> On 12/04/2016 03:16 PM, Ravi Desai wrote:
>> Is this something that we should change? The code is working
>
> I'm not sure what you'd change. In many places the Emacs C code relies 
> on the fact that unsigned arithmetic is modulo 2**N, where N is the 
> width of the unsigned integer, so that (for example) converting -1 to 
> unsigned yields UINT_MAX. XLI and XIL are intended for low-level use, 
> where this part of C semantics is assumed to be well-understood.
>
Ah, ok.  I was thrown off by the lack of explicit casting.  Sorry about 
that, and thanks for the explanation.

Re: EMACS_INT to EMACS_UINT

[Paul Eggert]

On 12/05/2016 05:56 AM, Ravi Desai wrote:
> I was thrown off by the lack of explicit casting.

All other things being equal I prefer ordinary assignment to explicit 
casting when either will do. That way, the compiler is more likely to 
catch typos.

Re: EMACS_INT to EMACS_UINT

[Daniel Colascione]

On 12/05/2016 09:23 AM, Paul Eggert wrote:
> On 12/05/2016 05:56 AM, Ravi Desai wrote:
>> I was thrown off by the lack of explicit casting.
>
> All other things being equal I prefer ordinary assignment to explicit
> casting when either will do. That way, the compiler is more likely to
> catch typos.

C++'s cast operators are be useful here --- for example, const_cast lets 
you cast a variable from const foo* to a foo* without inadvertently 
casting a foo* to a bar* if the type of the variable changes to const bar*.

The GDB people are slowly migrating their C-style codebase to C++, and 
without turning it into a a GoF book appendix. Maybe we can do the same 
someday.

Re: EMACS_INT to EMACS_UINT

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Mon, 5 Dec 2016 09:47:34 -0800
> Cc: emacs-devel@gnu.org
> 
> The GDB people are slowly migrating their C-style codebase to C++

Not slowly at all, watch gdb-patches.