Thanks to everyone for the excellent feedback. I've submitted an RFC
incorporating many of the ideas from the discussion:
https://github.com/rust-lang/rfcs/pull/146
On Fri, Jun 27, 2014 at 5:58 PM, Patrick Walton pcwal...@mozilla.com
wrote:
On 6/27/14 1:31 AM, Igor Bukanov wrote:
This bug
On 27/06/14 01:45 AM, Gregory Maxwell wrote:
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
not going to use checked arithmetic
This bug would be harmless in safe code in Rust as exploiting it
requires array access without bound checking.
On 27 June 2014 07:07, Tony Arcieri basc...@gmail.com wrote:
Thought I'd just throw this one on the fire ;)
On 6/27/14 1:31 AM, Igor Bukanov wrote:
This bug would be harmless in safe code in Rust as exploiting it
requires array access without bound checking.
Correct. This is a prime example of what I was talking about in my
earlier message: weaponizing integer overflows is much more difficult in
a
Thought I'd just throw this one on the fire ;)
http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
On 27/06/14 01:07 AM, Tony Arcieri wrote:
Thought I'd just throw this one on the fire ;)
http://blog.securitymouse.com/2014/06/raising-lazarus-20-year-old-bug-that.html
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com
wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
not going to use checked arithmetic types. Every branch that the
programmer
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
not going to use checked arithmetic types. Every branch that the
programmer
On 27/06/14 01:38 AM, Tony Arcieri wrote:
On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
It's a perfect example of a case where this feature wouldn't have
helped. Performance critical loops with years of micro-optimization are
I wasn't thinking of subtyping u32w to u32. I actually don't think that
u32 should be convertible to u32w (or vice-versa) without an explicit
cast. For array slices, it would have to be a transmute-like function,
e.g. fn as_wrapping'a(s:'a [u32])-'a [u32w] { unsafe { transmute(s) } }
On 26.06.2014 00:04, Vadim Chugunov wrote:
I wasn't thinking of subtyping u32w to u32. I actually don't think that
u32 should be convertible to u32w (or vice-versa) without an explicit
cast. For array slices, it would have to be a transmute-like function,
e.g. fn as_wrapping'a(s:'a
On 24/06/14 01:55 AM, Jerry Morrison wrote:
On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
On 24/06/14 01:17 AM, Jerry Morrison wrote:
Does `checked { }` mean all functions within that scope use
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply saying stuff is unspecified and
not actually
On 24/06/14 10:57 AM, Lars Bergstrom wrote:
On Jun 23, 2014, at 7:16 PM, John Regehr reg...@cs.utah.edu wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a
On 24/06/14 11:12 AM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand why this would be better than either `checked {}` or
checked operators along with an opt-in lint to catch unchecked
operators. It's far better than simply
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here.
Am I supposted to respond in kind? A language
On 24/06/14 02:51 PM, Gregory Maxwell wrote:
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay danielmi...@gmail.com wrote:
A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.
This seems to be getting a by high spirited here.
On 24/06/14 02:34 PM, Daniel Micay wrote:
You haven't explained how this is going to cause security issues in
Rust, when the language is guaranteed to be memory safe outside of
`unsafe` blocks. The `unsafe` blocks are low-level, performance critical
code where unnecessary overflow checks are
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning the
goals of Rust. The team has not deviated from their objective of the Rust
model. Kudos.)
I do not need compiler switches nor do I want them.
I want the
On 24/06/14 03:33 PM, Thad Guidry wrote:
I completely agree with Daniel in all points on this thread. (he
aggressively states over and over his stance and the teams concerning
the goals of Rust. The team has not deviated from their objective of the
Rust model. Kudos.)
Well, I don't speak for
On Tue, Jun 24, 2014 at 11:58 AM, Daniel Micay danielmi...@gmail.com
wrote:
That's why I support adding attributes but turning wrapping on overflow
on and off for a scope. You can indicate whether wrapping is considered
correct in that scope, meaning you either expect it to wrap or you have
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping and non-wrapping calculations in the
same
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
Yeah. And would programmers also have to convert each literal, like in the
Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode;
because adding a non-wraparound integer and a wraparound integer is
ambiguous?
Hey, it's just 5 more arithmetic operators. (A building architect
On 24/06/14 08:39 PM, Vadim Chugunov wrote:
I mostly agree, though for #1, I think that new int types would be more
appropriate. A set of special operators seems like an overkill for a
relatively infrequently used functionality. Annotations are too broad
(what if I need to do both wrapping
On Tue, Jun 24, 2014 at 5:48 PM, Jerry Morrison jhm...@gmail.com wrote:
Yeah. And would programmers also have to convert each literal, like in the
Java-ish hashCode() example:
result = (wint) 31 * result + (wint) areaCode;
because adding a non-wraparound integer and a wraparound integer is
On Wed, Jun 25, 2014 at 6:58 AM, Daniel Micay danielmi...@gmail.com wrote:
Rust has been consistently opposed to adding compiler switches changing
the meaning of the code. The metadata belongs *in the code* itself, and
you are free to flip wrapping on/off for whatever reason in the code
On 23/06/14 14:46, comex wrote:
On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay danielmi...@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
I would think that something simple like
let mut sum = 0;
for x in some_int_array.iter() {
sum += x;
}
would be very hard to vectorise with unwinding integer operations.
It sounds like there are two problems. First, you need to give up on
precise exceptions. So the code
Ada's approach to integer overflows is substantially similar to AIR
Isn't Ada's response to overflow implementation-defined?
On Mon, Jun 23, 2014 at 11:37 AM, John Regehr reg...@cs.utah.edu wrote:
I would think that something simple like
let mut sum = 0;
for x in
On 22/06/14 12:16 PM, SiegeLord wrote:
On 06/22/2014 11:32 AM, Benjamin Striegel wrote:
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge cases are the norm, not the
exception, and where 80/20 does not apply.
Even in systems
Ada's approach to integer overflows is substantially similar to AIR
Isn't Ada's response to overflow implementation-defined?
Sort of.
First, the standard seems to require a Constraint_Error when signed
integer overflow happens. For example, on page 47 of the ADA 2012 standard:
For a
On 23/06/14 04:10 PM, Tony Arcieri wrote:
On Monday, June 23, 2014, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust is not a language designed for an imaginary sufficiently smart
compiler. It targets real architectures and the real LLVM backend.
I
On 23/06/14 04:01 PM, John Regehr wrote:
I doubt it, since Swift has a high level IR above LLVM IR and the
implementation isn't open-source. The language-specific optimizations
like removing overflow / bounds checks based on type system rules will
almost certainly be done on the high-level SIL
On 23/06/14 04:00 PM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay danielmi...@gmail.com wrote:
The discussion here is about checking for both signed / unsigned integer
overflow, as in passing both `-fsanitize=signed-integer-overflow` and
On Mon, Jun 23, 2014 at 3:50 PM, Daniel Micay danielmi...@gmail.com wrote:
I doubt it, since Swift has a high level IR above LLVM IR and the
implementation isn't open-source. The language-specific optimizations
like removing overflow / bounds checks based on type system rules will
almost
On 23/06/14 03:59 PM, Cameron Zwarich wrote:
On Jun 22, 2014, at 4:12 PM, Patrick Walton pcwal...@mozilla.com wrote:
On 6/22/14 2:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too
On 6/23/14 1:55 PM, Daniel Micay wrote:
It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.
I agree with your general concerns, but I should nitpick that it won't
be slower than JavaScript, since JS
On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.
I don't see 'checked { }' anywhere in the discussion before this
message...
On 6/23/14 2:04 PM, comex wrote:
On Mon, Jun 23, 2014 at 4:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.
I don't see 'checked { }' anywhere in the
On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay danielmi...@gmail.com wrote:
It would be an enormous mistake to ship a language with region typing /
move semantics and worse before than Java.
You keep saying that, but if the argument is to use Swift's approach, i.e.:
Non-overflow operators: +
On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay danielmi...@gmail.com wrote:
I already mentioned the issue of undefined overflow, and how using
inbounds pointer arithmetic is both higher-level (iterators) and just as
fast. It doesn't cover every case, but it covers enough of them that the
use
O Mon, Jun 23, 2014 at 2:08 PM, Tony Arcieri basc...@gmail.com wrote:
Want to perform well at TIOBE or other (micro)benchmarks? Use the overflow
operators!
I meant http://shootout.alioth.debian.org here, but yeah, I hope you get
the idea ;)
--
Tony Arcieri
On 23/06/14 04:58 PM, Patrick Walton wrote:
On 6/23/14 1:55 PM, Daniel Micay wrote:
It's not much a systems language if it's slower than an inner loop in a
JavaScript program without going out of your way to avoid the overhead.
I agree with your general concerns, but I should nitpick that it
On 23/06/14 05:11 PM, Gregory Maxwell wrote:
Calling things 'slower than java' is a little bit hyperbole with the
actual numbers posted here. But I agree any non-trivial slowdown by
default would adversely impact adoption, I don't consider that
desirable.
It's really not hyperbole. Java's
I feel like Rust might be missing out on the free lunch I expect Swift to
provide
I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest benefactor
of LLVM, which powers the C compiler their OS is built with, the
On 23/06/14 05:08 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
It would be an enormous mistake to ship a language with region typing /
move semantics and worse before than Java.
You keep saying
On 23/06/14 05:38 PM, Benjamin Striegel wrote:
I feel like Rust might be missing out on the free lunch I expect Swift
to provide
I think that it may be unfounded to expect Swift to spur drastic
improvements to any aspect of LLVM. Apple is already the biggest
benefactor of LLVM, which powers
On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay danielmi...@gmail.com wrote:
Rust is a performance-centric systems language, Swift is not.
You say that, but I don't see how it applies to my argument. 2 of the 3
options I proposed are purely additive changes to Rust that would not
affect at all
On 23/06/14 05:57 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
Rust is a performance-centric systems language, Swift is not.
You say that, but I don't see how it applies to my argument. 2 of the 3
On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay danielmi...@gmail.com wrote:
The language shouldn't be designed around the hypothetical good will of
a corporation. Anyway, I don't know why Swift would have the high-level
SIL IR layer if that's not where they plan on doing these optimizations.
On Mon, Jun 23, 2014 at 3:08 PM, Tony Arcieri basc...@gmail.com wrote:
To flip the question around: what's wrong with Swift's approach?
Or perhaps to ask a less pointed question, what's wrong with Swift's
approach besides making the slow operators the default?
--
Tony Arcieri
On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
I'd like to also note that Apple has no external incentive to improve Swift.
Objective-C was a dead language before Apple's fiat rocketed it into the
position of world's third-most-popular programming language.
On 23/06/14 06:08 PM, Tony Arcieri wrote:
On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay danielmi...@gmail.com
mailto:danielmi...@gmail.com wrote:
The language shouldn't be designed around the hypothetical good will of
a corporation. Anyway, I don't know why Swift would have the
On 23/06/14 06:34 PM, comex wrote:
On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel
ben.strie...@gmail.com wrote:
I'd like to also note that Apple has no external incentive to improve Swift.
Objective-C was a dead language before Apple's fiat rocketed it into the
position of world's
On 23/06/14 08:16 PM, John Regehr wrote:
I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at a higher scope.
I'm just
the fact is that everyone is an optimist when it comes to integer
overflow bugs. People just do not think they're going to get bitten.
I agree, and I don't think anyone else here is going to try to argue that
this doesn't cause real bugs. As so often seems to be the case, language
design
In short:
- everybody wants checked integer arithmetic because it helps to
write better code (thanks to compile time and runtime errors)
- nobody wants to pay the price in performances, but maybe in the
future, hardware++ will make it easier... or so on...
What about:
- Defining safe integer
On 23/06/14 11:58 PM, François-Xavier Bourlet wrote:
In short:
- everybody wants checked integer arithmetic because it helps to
write better code (thanks to compile time and runtime errors)
- nobody wants to pay the price in performances, but maybe in the
future, hardware++ will make it
On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay danielmi...@gmail.com wrote:
On 23/06/14 04:00 PM, Gregory Maxwell wrote:
On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay danielmi...@gmail.com
wrote:
The discussion here is about checking for both signed / unsigned integer
overflow, as in
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens there should also be a module-level
attribute alternative to avoid unnecessary
On 24/06/14 01:22 AM, comex wrote:
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens there should also be a module-level
attribute
On 24/06/14 01:34 AM, Daniel Micay wrote:
On 24/06/14 01:22 AM, comex wrote:
On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison jhm...@gmail.com wrote:
Does `checked { }` mean all functions within that scope use checked-integer
arithmetic? This sounds great to me.
Bikeshed: If this happens
On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 24/06/14 01:17 AM, Jerry Morrison wrote:
Does `checked { }` mean all functions within that scope use
checked-integer arithmetic? This sounds great to me.
It would only apply to local operations. It's not
I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right whenever
going from one mode to the other is going to be a lot of boilerplate.
Instead, why not
On Sat, Jun 21, 2014 at 3:31 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 5:36 PM, Gábor Lehel glaebho...@gmail.com wrote:
On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison jhm...@gmail.com wrote:
On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel glaebho...@gmail.com
On Sat, Jun 21, 2014 at 11:21 PM, Vadim Chugunov vadi...@gmail.com wrote:
My 2c:
The world is finally becoming security-conscious, so I think it is a only
matter of time before architectures that implement zero-cost integer
overflow checking appear. I think we should be ready for it when
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust code
should not require absolute speed
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge
Because of memory safety? Because you want low-level control without
absolute speed? Because of a small memory footprint? Because of having a
good async story without giving up a lot of speed?
There are plenty of other features to Rust then absolute speed. Just
because that's *your* usecase for
There are plenty of other features to Rust then absolute speed.
You're right. Here are the three primary features of Rust, in decreasing
order of importance:
1. Memory safety
2. C++ performance
3. Safe concurrency
Notably, correctness in the face of integer overflow is merely a
On 22.06.2014 17:32, Benjamin Striegel wrote:
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust
code should not require absolute speed
This is a mistaken assumption. Systems programming exists on the
I don't think I was ever Railing against the incorrectness of overflow
semantics? I was just pointing out that your (imo pretty hostile?) message
about If you don't require absolute speed, why are you using Rust?
doesn't really ring true. Most C++ programmers don't even require absolute
speed.
On 06/22/2014 11:32 AM, Benjamin Striegel wrote:
This is a mistaken assumption. Systems programming exists on the extreme
end of the programming spectrum where edge cases are the norm, not the
exception, and where 80/20 does not apply.
Even in systems programming not every line is going to be
On 22 June 2014 17:06, Florian Zeitz flo...@babelmonkeys.de wrote:
To me the point of this discussion boils down to this:
I think we can all agree that having checked arithmetic is worthwhile.
Rust already has it as e.g. `.checked_add()'.
I think it might even be non-controversial that it is
I apologize for being hostile. As Florian has noted, we're just arguing
about the default behavior here. It is my opinion that checked behavior by
default will make Rust unsuitable for filling C++'s niche, and send the
message that we are not serious about performance.
On Sun, Jun 22, 2014 at
On 6/21/14 4:10 PM, Daniel Micay wrote:
http://ref.x86asm.net/coder64.html
I don't see enough gaps here for the necessary instructions.
I think all that Intel would have to do is to resurrect INTO (0xce) and
optimize the case in which INTO immediately follows an overflowable
arithmetic
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect, that's icing on the cake.
It's never going to be free or even cheap. Replacing
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes, but the default behavior
is no check? IMO this would be the best of both worlds, because I would
assume that one would
For some applications, Rust’s bounds checks and the inability of rustc to
eliminate them in nontrivial cases will already be too much of a performance
sacrifice. What do we say to those people? Is it just that memory safety is
important because of its security implications, and other forms of
On 22/06/14 11:39 AM, Evan G wrote:
Because of memory safety?
Most modern languages are memory safe. They're also significantly easier
to use than Rust, because the compiler / runtime is responsible for
managing object lifetimes.
Because you want low-level control without absolute speed?
I'm
On 22/06/14 11:32 AM, Benjamin Striegel wrote:
Even though Rust is a performance conscious language (since it aims at
displacing C and C++), the 80/20 rule still applies and most of Rust
code should not require absolute speed
This is a mistaken assumption. Systems programming exists on the
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes, but the default
behavior is no check? IMO this would be the best of
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging purposes,
On 22/06/14 05:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too much of a
performance sacrifice. What do we say to those people? Is it just that
memory safety is important because of
On 22/06/14 05:48 PM, Masklinn wrote:
On 2014-06-22, at 23:31 , Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
On 22/06/14 06:37 AM, Matthieu Monrocq wrote:
I am not a fan of having wrap-around and non-wrap-around types, because
whether you use wrap-around arithmetic or not is, in the end, an
implementation detail, and having to switch types left and right
whenever going from one mode to the other is
I think a reasonable middle ground is to have checked operators that look a
little funny. Kind of like swift, but in reverse:
malloc((number_of_elements +~ 12) *~ size_of::int())
Where adding a ~ to the end of an operator makes it check for overflow.
This would certainly look nicer than stuff
On 6/22/14 2:12 PM, Cameron Zwarich wrote:
For some applications, Rust’s bounds checks and the inability of rustc
to eliminate them in nontrivial cases will already be too much of a
performance sacrifice. What do we say to those people? Is it just that
memory safety is important because of its
On Sun, Jun 22, 2014 at 05:26:47PM -0400, Daniel Micay wrote:
Rust's design is based on the assumption that performance cannot be
achieved simply by having highly optimized inner loops. It takes a whole
program approach to performance by exposing references as first-class
values and
On Sun, Jun 22, 2014 at 11:05 PM, Daniel Micay danielmi...@gmail.com
wrote:
On 22/06/14 09:31 AM, Gábor Lehel wrote:
The prospect of future architectures with cheaper (free) overflow
checking isn't my primary motivation, though if we also end up better
prepared for them as a side effect,
Makes sense, but I am curious, how do you see adding this post-1.0? Would
you:
- add overflow-checked int types and tell everybody to use them instead of
the default ones from that point on
- declare that in Rust2 integers are overflow-checked, and have everybody
port their Rust1 code. (Well,
Apologies for adding heat to the discussion. The industry needs to make
progress on security/safety-critical systems, and Rust does a great deal
for that by bringing memory safety to a C/C++ alternative.
This post about hardware traps for integer overflow
http://blog.regehr.org/archives/1154 is
On Sun, Jun 22, 2014 at 2:31 PM, Daniel Micay danielmi...@gmail.com wrote:
On 22/06/14 05:09 PM, Rick Richardson wrote:
Apologies if this has been suggested, but would it be possible to have a
compiler switch that can add runtime checks and abort on
overflow/underflow/carry for debugging
On 6/22/14 5:34 PM, Vadim Chugunov wrote:
Modern C++ compilers often have a bunch of runtime checks (stack
overflow protectors, iterator invalidation detectors, and so on) that
may be enabled or disabled, and nobody bats an eye at that.
I'm not so sure. C++ is notoriously bad at dynamic
On 22/06/14 07:43 PM, Vadim Chugunov wrote:
Makes sense, but I am curious, how do you see adding this post-1.0?
Would you:
- add overflow-checked int types and tell everybody to use them instead
of the default ones from that point on
- declare that in Rust2 integers are overflow-checked,
On 22/06/14 07:26 PM, Gábor Lehel wrote:
Coincidentally, I didn't propose it. I proposed one implementation with
owned allocation (which we already have) in the `prelude` and one with
tracing GC allocation in the `gc` module.
Then I don't understand why we would have one for task-local
On 22/06/14 08:25 PM, Jerry Morrison wrote:
The post also links to Wikipedia on Intel MPX
http://en.wikipedia.org/wiki/Intel_MPX: Intel is adding x86 extensions
to aid memory safety! I think it's for array bounds checking, but the
article is unclear.
It's for faster (but not free) array
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
SIGFPE / SIGSEGV on *nix) into well defined
On 6/22/14 8:52 PM, Patrick Walton wrote:
On 6/22/14 8:46 PM, Daniel Micay wrote:
It's for faster (but not free) array bounds checking. I don't think Rust
will be able to use it because it unwinds on out-of-bounds rather than
aborting, and it will be difficult to turn the OS support (perhaps
1 - 100 of 153 matches
Mail list logo
