unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: pipcet@gmail.com, Emacs-devel@gnu.org
Subject: Re: Emacs port to gcc -fcheck-pointer-bounds
Date: Sat, 9 Dec 2017 23:10:43 -0800	[thread overview]
Message-ID: <e3b5c988-cf0f-caa5-7acd-3fb7ea2c883c@cs.ucla.edu> (raw)
In-Reply-To: <83k1xwuwq3.fsf@gnu.org>

On 12/09/2017 12:33 AM, Eli Zaretskii wrote:
> can you say a few words
> about the idea of your implementation of the support for
> "-fcheck-pointer-bounds"?


Sure. Three basic points.

1. The Emacs C code should store pointer values only in objects declared to be 
of type pointer. Otherwise, every time Emacs converted an integer to a pointer, 
machine code generated by -fcheck-pointer-bounds would disable bounds checking 
for that pointer (which would defeat the point of bounds checking).

This is what the first patch does. I like this patch anyway, since it cleans up 
the Emacs internals a bit and it doesn't significantly affect performance in the 
typical case where -fcheck-pointer-bounds is not used.

This first patch does not mean Emacs can't cast integers to pointers; that's OK. 
Emacs just can't cast pointers to integers and back again and then dereference 
the result and expect pointer-bounds checking to catch errors there.

2. With the 1st patch installed, building with -fcheck-pointer-bounds makes 
Emacs crash due to some false alarms. A typical example is that Emacs takes two 
individually valid but unrelated pointers P and Q, computes Q-P, and then later 
dereferences by computing P[Q - P], which crashes because Q-P falls outside P's 
bounds. The 2nd patch inserts the minimal changes to Emacs to avoid these 
crashes, by widening P's bounds in such cases.

3. The downside of the 2nd patch is that pointer bounds are often made too wide, 
so bounds checking won't catch some errors that it could easily catch. To fix 
some of this, the 3rd patch tightens pointer bounds when that is easy. This 
patch does not attempt to tighten bounds in all cases, as that would involve too 
many changes to the code and would make bounds-checking even slower than it is. 
It merely tightens bounds in a few strategic places, mostly in allocators, so 
that bounds errors are likely to be caught. It's a cost/benefit guesswork where 
I've tried to minimize development and runtime cost while maximizing 
error-catching benefit.




  reply	other threads:[~2017-12-10  7:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-07  7:34 Emacs port to gcc -fcheck-pointer-bounds Paul Eggert
2017-12-08 13:45 ` Eli Zaretskii
2017-12-08 22:06   ` Paul Eggert
2017-12-09  8:33     ` Eli Zaretskii
2017-12-10  7:10       ` Paul Eggert [this message]
2017-12-10 17:27         ` Eli Zaretskii
2017-12-11  7:54           ` Paul Eggert
2017-12-11 15:26             ` Eli Zaretskii
2017-12-12 23:35               ` Paul Eggert
2017-12-13 16:20                 ` Eli Zaretskii
2017-12-13 18:30                   ` Paul Eggert
2017-12-13 19:17                     ` Stefan Monnier
2017-12-13 19:39                       ` Paul Eggert
2017-12-18  2:47                       ` Paul Eggert
2017-12-08 16:13 ` Pip Cet
2017-12-08 22:09   ` Paul Eggert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e3b5c988-cf0f-caa5-7acd-3fb7ea2c883c@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=Emacs-devel@gnu.org \
    --cc=eliz@gnu.org \
    --cc=pipcet@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).