On 12/11/2017 07:26 AM, Eli Zaretskii wrote:
> So we will have two different data types implementing a Lisp object,
> one --with-wide-int and another without it?  That sounds suboptimal to
> me.

I figured out a simple fix to get it to work --with-wide-int (see first 
attached patch), so I hope this issue is moot now, and boldly installed 
the patches into master, along with the attached followup patches.

> Why not reserve the new representation to the -fcheck-pointer-bounds
> builds only?

Although we could change lisp.h to do that, I'd rather not. Having 
Lisp_Object be an opaque pointer type is a win even for non-developers 
who merely make minor changes to the C code and are not using 
-fcheck-pointer-bounds or --enable-check-lisp-object-type or anything 
like that. In practice it's error-prone when Lisp_Object is an integer 
type, and if we can easily avoid these errors we should.

Here's another way to think about it. Our current practice of defaulting 
to --enable-check-lisp-object-type for developers is an outgrowth of the 
fact that integer Lisp_Objects are so error-prone. Unfortunately, this 
practice is dicey in its own right, as it means developers are dealing 
with different object code than non-developers. I would favor going back 
to the old practice of disabling --enable-check-lisp-object-type by 
default, even for developers, once we've shaken out the change that I 
just installed. That way, developers and non-developers will default to 
more-similar machine code.