[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Sun Jun 22 22:31:08 PDT 2014


On 23/06/14 01:16 AM, Cameron Zwarich wrote:
> On Jun 22, 2014, at 10:00 PM, Daniel Micay <danielmicay at gmail.com
> <mailto:danielmicay at gmail.com>> wrote:
> 
>> On 23/06/14 12:49 AM, Cameron Zwarich wrote:
>>> On Jun 22, 2014, at 9:35 PM, Daniel Micay <danielmicay at gmail.com
>>> <mailto:danielmicay at gmail.com>
>>> <mailto:danielmicay at gmail.com>> wrote:
>>>
>>>> An operation that can unwind isn't pure. It impedes code motion such as
>>>> hoisting operations out of a loop, which is very important for easing
>>>> the performance issues caused by indexing bounds checks. LLVM doesn't
>>>> model the `nounwind` effect on functions simply for fun.
>>>
>>> It gets easier to optimize if you adopt a less precise model of
>>> exceptions. For example, you could pick a model where you preserve
>>> control dependence and externally visible side effects, but allow
>>> reordering in other cases. This does get tricky if destructors
>>> themselves have externally visible side effects that are dependent on
>>> intervening stores that can be elided.
>>>
>>> This probably requires whole-program compilation with some knowledge of
>>> externally visible side effects, or more restrictions placed on
>>> destructors than there are currently. It also is hard to make work with
>>> unsafe code, since unsafe code might require exact placement of
>>> unwinding for memory safety in destructors.
>>>
>>> Cameron
>>
>> Adding restrictions to destructors sounds like adding an effects system
>> to Rust. I think the trait system will get in the way of an attempt to
>> do that. For example, should a trait like `Eq` use pure methods? If
>> they're not pure, then no implementation can be considered pure in
>> generic code. Anything using that generic code can't be considered pure,
>> and so on.
> 
> We already have a need for limiting what destructors can do:
> 
> https://github.com/rust-lang/rust/issues/14875

I don't really see how it would be possible to fix that. It also causes
the failing while failing issue where we currently abort, so the claim
that Rust supports isolated task failure doesn't really pass the sniff
test. The poisoning of RWLock / Mutex is necessary (otherwise we might
as well just have try-catch and call it exceptions) and erodes the
"isolation" part too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140623/0326c4bb/attachment.sig>


More information about the Rust-dev mailing list