[llvm-dev] Reducing the number of ptrtoint/inttoptrs that are generated by LLVM
Juneyoung Lee via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 16 06:31:16 PST 2019
I think adding an option which analogous to -fwrapv is a good candidate for
addressing the concern.
Well, I didn't know that arithmetic on intptr_t was implementation defined
- I thought the arithmetic on intptr_t is equivalent to the integer types.
Thanks for the point.
On Wed, Jan 16, 2019 at 9:40 AM David Chisnall <David.Chisnall at cl.cam.ac.uk>
> On 15/01/2019 16:26, Juneyoung Lee wrote:
> > If C programmer wants to get distance between two different objects,
> > s/he can use (intptr_t)p - (intptr_t)q instead of p - q.
> That's fine for new code, but unless you're volunteering to audit the
> (roughly) 8 billion lines of open source C code and a corresponding
> (probably larger) amount of proprietary code, then making this
> assumption is going to break things.
> From the relatively small survey that we did of C idioms as part of the
> CHERI project, I can tell you that this is very widespread. This was
> something that we had to support (we considered only allowing pointer
> subtraction to yield a valid result when the operands referred to the
> same object and it broke pretty much everything we looked at).
> P.S. If you want to talk about the standard with respect to intptr_t,
> you might want to reread what the standard actually says about it,
> specifically that a) it's optional, and b) if it does exist the only
> operation that is guaranteed to work is a cast from a pointer to an
> intptr_t and back again - all arithmetic on intptr_t is implementation
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev