I think checked integer overflow could be a good idea, presuming the cost is reasonable, but I am somewhat skeptical of having it be enabled or disabled on a module-by-module basis. This would imply that if I move a function from one module to another, it stops working? It seems surprising. Having the overflow checking be based on the type seems more robust. But maybe this would not be a big issue in practice; after all, it's already the case that moving a function requires various corrections (name resolution etc) to account for the new scope. But somehow this feels "different" than those, because this would mean that compilation succeeds but the dynamic behavior silently changes.
In the past I had thought about saying that the unsized types (`uint`, `int`) are overflow checked but the sized types (`u32`, `i32`, etc) act as they do in C. But Roc's email made me reconsider if that is reasonable. Perhaps it's just too pat, and we would actually want a distinct family of "overflow-checked" types (perhaps a library, as Graydon suggests, though it seems like something that you might want to opt out of, rather than opt in). Definitely a Milestone 2 consideration ;) Niko On Wed, Apr 24, 2013 at 5:37 PM, Graydon Hoare <[email protected]> wrote: > On 13-04-23 04:53 PM, Robert O'Callahan wrote: > > On Wed, Apr 24, 2013 at 11:25 AM, Robert O'Callahan > > <[email protected] <mailto:[email protected]>> wrote: > > > > I don't think bignums are useful in a browser because as a browser > > developer I will choose data types that cover the ranges of values I > > want to handle. If I think I need to handle integer values that > > don't fit in 32 bits, I'll use a 64-bit integer type, or a floating > > point type. Overflow always means I have a bug*. > > > > > > Well, in C and C++ it does, and of course that's what most browser > > developers are going to be used to. > > > > If we could rely on checked overflows in Rust, then we could start to > > lean on that and declare that some tests that trigger overflow are > > simply tests where task failure is an acceptable result. (Offensive as > > this may to the cult of correctness, in practice priorities dictate we > > have to do this kind of thing all the time --- declare that a bug is not > > worth fixing as long as it's not exploitable.) > > Sure. I'd be happy to look into this as a mode for rust; I don't think > we can expect to make it "always on", but we could possibly make it > "reasonably easy to turn on" on a crate-by-crate basis. > > First thing to do is look into enabling it. There are a variety of > pieces lying around we could look into: > > http://llvm.org/docs/LangRef.html#range-metadata > http://llvm.org/docs/LangRef.html#arithmetic-with-overflow-intrinsics > http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation > http://embed.cs.utah.edu/ioc/ > > I suspect there's enough to work with there. It might require > duplicating some of the lowerings that clang does in rust's trans layer. > > -Graydon > _______________________________________________ > Rust-dev mailing list > [email protected] > https://mail.mozilla.org/listinfo/rust-dev >
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
