On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay 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 thinks can be avoided
On Tue, Jun 24, 2014 at 11:39 AM, Daniel Micay 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 where common idiomatic
On Mon, Jun 23, 2014 at 10:00 PM, Daniel Micay 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 attempting to tac
On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay 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 case for undefined s
On Mon, Jun 23, 2014 at 12:50 PM, Daniel Micay wrote:
> The discussion here is about checking for both signed / unsigned integer
> overflow, as in passing both `-fsanitize=signed-integer-overflow` and
> `-fsanitize=unsigned-integer-overflow`. Rust has defined signed overflow
> already so it doesn'
On Sat, Jun 21, 2014 at 5:18 AM, Diggory Hardy wrote:
> As far as I am aware, using theorem proving tools[1] to provide limits on
> value ranges is pretty hard and often computationally intensive to do in
> simple code. I've only seen prototype systems where the user is expected to
> write full co
On Wed, Jun 18, 2014 at 10:08 AM, Gábor Lehel wrote:
> core facts: wrapping is bad, but checking is slow. The current consensus
On this point, has anyone tried changing the emitted code for all i32
operations to add trivial checks, hopefully in a way that llvm can
optimize out when value analysis
On Wed, Jun 18, 2014 at 10:08 AM, Gábor Lehel wrote:
> memory safety bugs.) This is a step up from C's insanity of undefined
> behavior for signed overflow, where the compiler assumes that overflow
> *cannot* happen and even optimizes based on that assumption, but it's still
> a sad state of affai
On Sat, Apr 26, 2014 at 9:39 AM, Geoffroy Couprie wrote:
> Before writing production ready crypto code, some things must be tested
> carefully, like the ability to write constant time code, or a "secure"
> buffer implementation (wiped before freeing it). Constant time code is
> possible in theory
On Sat, Jan 11, 2014 at 5:49 PM, Nathan Myers wrote:
> No one would complain about a built-in "i128" type. The thing
> about a fixed-size type is that there are no implementation
> choices to leak out. Overflowing an i128 variable is quite
> difficult, and 128-bit operations are still lots faste
On Mon, Nov 11, 2013 at 12:27 PM, Greg wrote:
> Dear Mozilla, rust devs, and memory-safe enthusiasts everywhere,
>
> I'm very happy with the safety improvements that Rust brings.
>
> This is true innovation.
>
> At the same time, I am disappointed and quite concerned about Rust's
> unimaginative
On Tue, Sep 10, 2013 at 12:01 AM, John Mija wrote:
> After of reading an article seen in HN "Strange Loops: Ken Thompson and the
> Self-referencing C Compiler" (https://news.ycombinator.com/item?id=6355978)
>
> I'm worried if that issue could happens in the Rust compiler.
> Does Rust compiler is b
On Tue, Jul 2, 2013 at 1:00 PM, Graydon Hoare wrote:
> The largest supported _of the rust types_; I didn't (and don't) intend
> to have rust support f80 at all, since:
> - It's not an ieee754 basic format.
> - It's not a storage format; x87 loads and stores 32/64 bit values,
> it's just an
On Tue, Apr 30, 2013 at 10:08 AM, Max Cantor wrote:
> I know this will be an unpopular opinion, but pure functions would be a
> massive win for Rust, especially if the eventual goal is high performance,
> highly parallelizable (browser rendering engines..) development.
Being able to annotate a fu
Graydon Hoare wrote:
> I believe you can trap
> this in C presently with a gcc flag too (-ftrapv); but it's a flag
> rarely turned on.
-ftrapv basically doesn't work, e.g. doesn't work (at all?) on x86_64,
doesn't prevent algebraic simplification which assumes no overflow
(and thus hides the overf
swede at earthling.net wrote:
> While T-division is the most common choice (used by C, C++, etc) F-division
> is not uncommon. I've confirmed that Python and Ruby use F-division, and
> Wikipedia claims that TCL and D do too. F-division behavior won't be
> surprising or hard to explain to any use
16 matches
Mail list logo
