[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Robert O'Callahan robert at ocallahan.org
Sun Jan 12 17:01:43 PST 2014

On Sun, Jan 12, 2014 at 12:59 PM, Patrick Walton <pcwalton at mozilla.com>wrote:

> On 1/10/14 10:08 PM, Daniel Micay wrote:
>> I don't think failure on overflow is very useful. It's still a bug if
>> you overflow when you don't intend it.
> Of course it's useful. It prevents attackers from weaponizing
> out-of-bounds reads and writes in unsafe code.

Yes. And as a browser developer, I still want trap-on-overflow by default
in the browser if it can be cheap. Overflowing integer coordinates can lead
to infinite loops and incorrect layout or rendering, the latter of which
can occasionally have security implications. Task failure is better than
both of those. Generally, the sooner we detect bugs and fail the more
robust we will be against malicious input. Being able to harden the code
against a common class of bugs without making the language any more
complicated is very attractive to me.

I examined Gecko's gfx module a while back and determined that the only
adds and subtracts that *should* overflow were in hash functions, a
miniscule fraction of the total. Adding crypto and codecs into the mix
wouldn't make much difference. (You aren't going to write those in Rust
without SIMD anyway.)

Daniel's points about cost are interesting but there's a lot of things that
could be tried before declaring the problem intractable. Since most Rust
side effects commute with task failure, you could do a lot of trap code
motion and coalescing. The absence of overflow lets the compiler reason
more effectively about arithmetic, benefiting optimizations such as array
bounds check elimination. Range analysis becomes very important so you want
work at it harder. Etc.

Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140113/b058d713/attachment.html>

More information about the Rust-dev mailing list