Re: Emacs port to gcc -fcheck-pointer-bounds

[Paul Eggert]

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.