Re: Making --with-wide-int the default

[David Kastrup]

Paul Eggert <address@hidden> writes:

> On 11/15/2015 08:01 AM, David Kastrup wrote:
>> I can tell, and
>>
>> git grep XINT
>>
>> shows lots of assignments to variables of type int rather than
>> EMACS_INT.  I think that there should be macros XINT, XUINT, XEINT (for
>> EMACS_INT) which trigger a range error when the value does not fit the
>> respective range.  Possibly also XLONG and XULONG but I'm not sure we
>> actually have platforms where long/int are different.
>
> There's no need XEINT etc., as this work has already been done, using
> macros like CHECK_TYPE_RANGED_INTEGER to make sure that XINT returns
> values in range for a C integer type.

This has to be called explicitly.  There are several consequences of the
current choices: for one thing, one cannot enable C compiler warnings
about too small integer types since any assignment of XINT to an int
will trigger such a warning, making them useless for detecting actual
problems.  As one consequence, every single use of XINT needs manual
code review.

As another consequence, we'll have to redo all of the code review when
moving to Guile and/or arbitrary precision integers since the current
code obviously assumes that EMACS_INT is large enough for any integer
value representable in Lisp.

Guile has all of

-- C Function: char scm_to_char (SCM x)
 -- C Function: signed char scm_to_schar (SCM x)
 -- C Function: unsigned char scm_to_uchar (SCM x)
 -- C Function: short scm_to_short (SCM x)
 -- C Function: unsigned short scm_to_ushort (SCM x)
 -- C Function: int scm_to_int (SCM x)
 -- C Function: unsigned int scm_to_uint (SCM x)
 -- C Function: long scm_to_long (SCM x)
 -- C Function: unsigned long scm_to_ulong (SCM x)
 -- C Function: long long scm_to_long_long (SCM x)
 -- C Function: unsigned long long scm_to_ulong_long (SCM x)
 -- C Function: size_t scm_to_size_t (SCM x)
 -- C Function: ssize_t scm_to_ssize_t (SCM x)
 -- C Function: scm_t_ptrdiff scm_to_ptrdiff_t (SCM x)
 -- C Function: scm_t_int8 scm_to_int8 (SCM x)
 -- C Function: scm_t_uint8 scm_to_uint8 (SCM x)
 -- C Function: scm_t_int16 scm_to_int16 (SCM x)
 -- C Function: scm_t_uint16 scm_to_uint16 (SCM x)
 -- C Function: scm_t_int32 scm_to_int32 (SCM x)
 -- C Function: scm_t_uint32 scm_to_uint32 (SCM x)
 -- C Function: scm_t_int64 scm_to_int64 (SCM x)
 -- C Function: scm_t_uint64 scm_to_uint64 (SCM x)
 -- C Function: scm_t_intmax scm_to_intmax (SCM x)
 -- C Function: scm_t_uintmax scm_to_uintmax (SCM x)
     When X represents an exact integer that fits into the indicated C
     type, return that integer.  Else signal an error, either a
     ‘wrong-type’ error when X is not an exact integer, or an
     ‘out-of-range’ error when it doesn’t fit the given range.

     The functions ‘scm_to_long_long’, ‘scm_to_ulong_long’,
     ‘scm_to_int64’, and ‘scm_to_uint64’ are only available when the
     corresponding types are.

What does that mean?  For one thing it means that the C compiler can
have all of its warnings for losing significant bits enabled
meaningfully.  For another it means that converting a Lisp integer to
something used is a C routine will either succeed or throw an error.

The reverse conversions all succeed, and naturally without ever losing
any precision (as opposed to our current conversion which, I think,
silently drops a few bits from the top of any EMACS_INT when converting
to Lisp_Object .

Integer overflows are a rather popular source of security
vulnerabilities and/or crashes, so having them under control by default
is a good idea and means that we don't need to start rereviewing
everything whenever our integer representation changes.

-- 
David Kastrup