[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs port to gcc -fcheck-pointer-bounds
From: |
Paul Eggert |
Subject: |
Re: Emacs port to gcc -fcheck-pointer-bounds |
Date: |
Tue, 12 Dec 2017 15:35:01 -0800 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 |
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.
0001-Port-fcheck-pointer-bounds-to-with-wide-int.patch
Description: Text Data
0002-Fix-recently-introduced-cast-typo.patch
Description: Text Data
- Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/07
- Re: Emacs port to gcc -fcheck-pointer-bounds, Eli Zaretskii, 2017/12/08
- Re: Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/08
- Re: Emacs port to gcc -fcheck-pointer-bounds, Eli Zaretskii, 2017/12/09
- Re: Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/10
- Re: Emacs port to gcc -fcheck-pointer-bounds, Eli Zaretskii, 2017/12/10
- Re: Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/11
- Re: Emacs port to gcc -fcheck-pointer-bounds, Eli Zaretskii, 2017/12/11
- Re: Emacs port to gcc -fcheck-pointer-bounds,
Paul Eggert <=
- Re: Emacs port to gcc -fcheck-pointer-bounds, Eli Zaretskii, 2017/12/13
- Re: Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/13
- Re: Emacs port to gcc -fcheck-pointer-bounds, Stefan Monnier, 2017/12/13
- Re: Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/13
- Re: Emacs port to gcc -fcheck-pointer-bounds, Paul Eggert, 2017/12/17
Re: Emacs port to gcc -fcheck-pointer-bounds, Pip Cet, 2017/12/08