[llvm-dev] Reducing the number of ptrtoint/inttoptrs that are generated by LLVM

[Juneyoung Lee via llvm-dev]

Hello David,

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.

Juneyoung Lee

On Wed, Jan 16, 2019 at 9:40 AM David Chisnall <David.Chisnall at cl.cam.ac.uk>
wrote:

> 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).
>
> David
>
> 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
> defined.
>


-- 

Juneyoung Lee
Software Foundation Lab, Seoul National University
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190116/02eb2555/attachment.html>