Re: [rust-dev] Tail call compatibility

[Daniel Micay]

On 27/12/14 11:48 AM, Clark Gaebel wrote:
> The abi is allowed to change post 1.0. If it wasn't, we'd be stuck with
> cdecl forever and that sucks.
> 
> I've only seen fastcall used for intracrate leaf calls.
> 
> Servo and rustc are the two biggest rust projects.
> 
> The mailing list is mostly dead BTW. Consider bringing this up on
> discuss.rust-lang.org instead.
> 
> If you plan on playing with calling convention, aatch and I (cgaebel)
> have been considering a rust-specific one. You should drop by on irc
> some time if it interests you!
> 
> Happy to help,
> - Clark

The calling convention isn't actually relevant to guaranteed TCO.

It requires a simple language feature mapping to musttail.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Reading numbers from a mmap

[Daniel Micay]

On 10/12/14 01:08 PM, Matt wrote:
> Sorry if this has been covered before, and also that I'm a complete noob, but 
> I'm thinking about trying a first project in Rust, and trying to learn enough 
> to get started. 
> 
> My plan is for an on-disk key-value store. I'm going to end up writing arrays 
> of numbers to disk, and then needing to efficiently read them out of a 
> mmap-ed file. So I'm wondering how in Rust you efficiently/zero-copy-ly take 
> some slice of a read-only mmap and treat it as e.g. a vector of ints?
> 
> I see Vec.from_raw_parts() and Vec.from_raw_buf(), but I don't really 
> understand the difference between them, and also they seem like they just 
> give you a vector of the pointer's type, so I don't know how you use them 
> convert the u8s you get from MemoryMap.data() into a vector of a different 
> type, e.g. 32 bit ints.
> 
> It seems like there should be a higher level API for this kind of thing, 
> where "casting" a slice of a read-only memory buffer into an immutable vector 
> is not an unsafe operation (I mean, you can do that in Python ;) Either I 
> don't see it in the docs, or it doesn't exist yet; just wondering which :)
> 
> Thanks!
> 
> Matt

Keep in mind that the file won't be portable if you do this. It's why
it's not a common pattern.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Curious about instruction pointer being used to compute string offset

[Daniel Micay]

On 09/12/14 10:43 PM, C K Kashyap wrote:
> Hi,
> 
> Looks like on my ubuntu 64 bit, when I compile 
> 
>hello("ABCD");
> 
> I get 
> 
> 719e:   48 8d 05 e0 68 04 00lea0x468e0(%rip),%rax  
>  # 4da85 
> 71a5:   48 89 44 24 08 mov%rax,0x8(%rsp)
> 71aa:   48 c7 44 24 10 04 00movq   $0x4,0x10(%rsp)
> 71b1:   00 00
> 71b3:   e8 88 f6 ff ff callq  6840
> <_ZN5hello20h8ed5f876da0c3862eaaE>
> 
> 
> I was wondering why is %rip being used for getting to the string? Or am
> I understanding it incorrectly?
> 
> Regards,
> Kashyap

That's what position independent code looks like on x86_64.

https://en.wikipedia.org/wiki/Position-independent_code



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Overflow when benchmarking

[Daniel Micay]

On 28/11/14 12:18 PM, Matthieu Monrocq wrote:
> 
> In this case, I have never heard of automatically moving an automatic
> variable to the heap, however LLVM routinely uses the stack for
> dynamically allocated variables if it can prove their lifetime (probably
> restricted to fixed-size variables below a certain threshold).

LLVM doesn't have escape analysis for dynamic allocations. It only has
primitive dead store elimination for malloc/free. It could be taught to
do escape analysis, but it would probably need to be very conservative
and only do it for <= pointer size allocations by default.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Two mutable pointers to same memory address?

[Daniel Micay]

On 26/11/14 12:26 PM, grayfox wrote:
> Hey guys,
> 
> I'm really new to Rust (actually I've looked on Rust the last 5 hours the 
> first time) but I think I produced something that shouldn't be possible. From 
> the pointer guide I know that the following code will not compile because in 
> the end I would have two mutable pointers to the same address:
> 
> let x = 5i;
> let y = &x;
> let z = &x;
> 
> But in the following snippet I end up with two mutable pointer tmp and *i 
> which point both to the same address:
> 
> fn bar<'a>(i: &mut &'a int) {
> let mut tmp = *i;
> println!("{} {}", *tmp, **i);
> }
> 
> fn foo<'a>() {
> let mut i: &int = &mut 5;
> bar(&mut i);
> }
> 
> fn main() {
> foo();
> }
> 
> Maybe I don't understand the concept of the Rust memory concept enough but if 
> I understand everything correct so far this shouldn't compile but it does 
> actually.
> 
> Kind regards,
> 
> grayfox

I see two immutable refs being created from a mutable one, not two
aliasing mutable refs. The type of `tmp` is `&int`, not `&mut int`. The
fact that the variable is mutable just means that another immutable
pointer can be assigned to it - it's unnecessary, as is the `mut` on `i`
in `foo`.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Compiling static binary

[Daniel Micay]

On 15/11/14 05:24 PM, Paul Colomiets wrote:
> Hi Brian,
> 
> On Sat, Nov 15, 2014 at 11:23 PM, Brian Anderson  
> wrote:
>> I believe it is not possible to link to glibc statically. My understanding
>> is that to get a Rust binary that does not depend on a system-provided libc
>> at all we need to add explicit support for alternate libc
>> implementations[1].
>>
> 
> Thanks. This really explains why problem is so hard. It seems that
> it's possible to link to glibc, with the issue of non-working name
> resolution (which is pluggable in glibc) and dlopen (for obvious
> reasons). That would work for me for now.
> 
> Still, when you are talking about "system-provided libc", do you mean
> that if I would compile Rust on e.g. Alpine linux (which has musl libc
> by default), I will be able to link rust program with musl libc
> statically?

The limited static linking support in glibc is misleading, because it's
quite broken.

Here's a simple example of a performance bug (time it with and without
using -static):

#include 

int main(void) {
struct timespec ts;
for (unsigned i = 0; i < 100; i++) {
clock_gettime(CLOCK_MONOTONIC, &ts);
}
}

Unlike musl, glibc has no vdso support without dynamic linking.

Statically linking all libraries is also different than a *fully* static
binary which is incompatible with features like ASLR. Rust enables PIE
(full ASLR) by default so `-static` alone is poorly defined and will
likely break at compile-time or runtime.

Rust's current approach to FFI is to hard-wire the entire ABI of a
specific version / configuration of the library. It's unlikely that it
will work with musl at this time, despite musl's progress towards
support for the glibc ABI.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust Research Project Query

[Daniel Micay]

On 12/10/14 03:16 PM, Nick Cameron wrote:
> 
> On a different note, I would be really keen to see dynamic or static
> analysis of unsafe blocks to show that they do in fact re-establish the
> invariants that the rust compiler expects by the end of the unsafe
> block. I expect this is hard to do, but would be super-interesting research.

Unsafety isn't currently contained within unsafe blocks even in correct
code. The lack of unsafe fields means leaning on the privacy systems to
implement much of the unsafe code in the standard libraries.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust crypto highlights

[Daniel Micay]

On 30/09/14 01:44 AM, Tony Arcieri wrote:
> Sidebar on SBuf: I'd be curious how it could be written completely in
> terms of MemoryMap, or if MemoryMap needs to be extended to support
> mprotect() / VirtualProtect().

MemoryMap doesn't support controlling memory protections.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Timing vector inserts

[Daniel Micay]

On 25/09/14 03:17 PM, Fredrik Widlund wrote:
> http://lonewolfer.wordpress.com/2014/09/24/benchmarking-dynamic-array-implementations/
> 
> (disclaimer: *not* about comparing languages and claiming language X is
> "better" than language Y)
> 
> Kind regards,
> Fredrik Widlund

https://github.com/jemalloc/jemalloc/issues/126



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On the use of unsafe

[Daniel Micay]

On 22/09/14 06:45 PM, Manish Goregaokar wrote:
> As Chris mentioned, it's not about using the type system to create
> safety. We're assuming that exists, the idea is to gate unchecked access
> to the data (which /is/ required for libraries created for generic use)
> with the `unsafe` keyword. However, many seem to be of the opinion that
> `unsafe` is just for memory safety, in which case it would be nice to
> have a wider range of `unsafe` attributes (or something) which allow us
> to gate methods that are prone to SQL injection (etc etc). 
> 
> -Manish Goregaokar

It's not an opinion, it's how it's defined in the documentation (see the
Rust manual) and the compiler warns about unnecessary usage of `unsafe`
- which could be finished if there were `unsafe` fields.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On the use of unsafe

[Daniel Micay]

On 22/09/14 05:12 PM, Tony Arcieri wrote:
> On Mon, Sep 22, 2014 at 12:32 PM, Daniel Micay  <mailto:danielmi...@gmail.com>> wrote:
> 
> Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It
> uses `unsafe` as a memory safety boundary, and in this case breaking the
> invariant would be memory unsafe.
> 
> 
> I just want to say that I completely agree with you that "unsafe" is the
> wrong tool for the job here.
> 
> However there is still a problem I feel is potentially solved via type
> systems, not necessarily Rust's, only if Rust chooses to rise to the
> challenge.
> 
> After 1.0 might be a good time to start considering these problems. I
> know you already have enough work on your plate as-is. 

I think it can be solved by using visibility, along with providing a way
to override the visibility rules and call private functions. That means
replacing the current usage of visibility for memory safety with unsafe
fields though, but I think that's important to make the memory safety
boundary work properly anyway.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On the use of unsafe

[Daniel Micay]

On 22/09/14 03:21 PM, Chris Morgan wrote:
>> It's completely unnecessary actually.
> Would that it were. There was a time when I believed it was, but it's not.
> 
>> If a method requires a XSS-safe string, then it should take the
> XssSafeString parameter, which would implement Deref and would
> be built from a String by a method performing the necessary escaping.
> This sort of thing is the idea—building it all into the type system is
> the goal. The question was to do with getting around that, doing
> something that would *not* be safe. You can build as great a library
> with the type system as you like, but eventually someone will want—nay,
> need—an escape hatch. Perhaps they are dealing with a legacy system
> that, alas, requires broken behavior; or perhaps a performance issue
> with the normal way of doing it needs to be circumvented. This part,
> breaking the rules in a reasonable manner yet without it being so normal
> that everyone does it (*cough* PHP *cough*), is the part that was being
> discussed at that point.
> 
> I consider `unsafe` to be entirely justified here because we're dealing
> with data being able to break the invariants of the type. If, for an
> arbitrary example, we have an HTML chunk we are going to emit and wish
> to insert something known to be legal HTML as we emit it, there are
> shortcuts that can be taken. But if it was not in fact legal HTML, the
> invariants of the type are broken and the interpretation of the data no
> longer certain. Thus it should be marked image, just like the UTF-8
> constraint of strings.

Rust doesn't use `unsafe` to uphold the UTF-8 invariant of strings. It
uses `unsafe` as a memory safety boundary, and in this case breaking the
invariant would be memory unsafe.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On the use of unsafe

[Daniel Micay]

On 21/09/14 04:27 PM, Evan G wrote:
> Personally, I feel "safety" generalizes pretty well to "any concept
> that should be called out explicitly as unsafe"--not just memory
> safety.

That's not how Rust defines `unsafe`. It's open to misuse, and the
compiler will happily point out that it's not being used correctly via
the unnecessary unsafe lint.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On the use of unsafe

[Daniel Micay]

On 21/09/14 05:57 AM, Simon Sapin wrote:
> On 21/09/14 07:34, Daniel Micay wrote:
>> It's not intended to be used for anything other than memory safety.
> 
> It’s also used to maintain invariants, such as the bytes inside a String
> being valid UTF-8: String::push_bytes() is unsafe, but
> String::push_str() is not.

No, it's not used to maintain invariants unrelated to memory safety.

Strings assume the contents are UTF-8 and violating that invariant would
violate memory safety.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On the use of unsafe

[Daniel Micay]

On 21/09/14 02:29 AM, Tony Arcieri wrote:
> Traditionally in Rust, "unsafe" has centered around memory safety. The
> reference manual describes it as such:
> 
> http://doc.rust-lang.org/rust.html#unsafety
> 
> At Strange Loop, during Chris Morgan's talk, someone asked about using
> the type system to present SQL injection after he described using the
> type system to handle escaping.
> 
> He suggested using unsafe to call out when a SQL query is being made
> with a raw string.
> 
> On the one hand I really liked the clarity of calling out passing a raw
> string to a SQL driver as being inherently unsafe, but on the other hand
> it seems to be semantically different from Rust's traditional sense of
> what's unsafe.
> 
> Is it ok to extend unsafe to things which are unsafe from a security
> standpoint, or is this conflating concerns?
> 
> Should there be a standard way to express things which are potentially
> unsafe from a security standpoint but not necessarily from a memory
> safety standpoint?
> 
> I think something like that would be pretty cool. "insecure" ? ;)
> 
> -- 
> Tony Arcieri

It's not intended to be used for anything other than memory safety. The
requirements are the same across all libraries / applications. It's not
possible to represent the semantics of 'insecure' in the language as
that's very poorly defined and varies across domains and libraries.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust BigInt

[Daniel Micay]

On 19/09/14 12:46 PM, Jauhien Piatlicki wrote:
> Hi,
> 
> On 09/19/2014 06:40 PM, Matthieu Monrocq wrote:
>> Disclaimer, for the unwary, GMP is a GPL library; so using it implies
>> complying with the GPL license.
>>
> 
> LGPL afaik, so you can dynamically link with it in any case.

Static linking of a proprietary application is fine too, as long as
linkable object files are provided so the user can replace GMP with a
patched / updated library.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust BigInt

[Daniel Micay]

On 19/09/14 12:40 PM, Matthieu Monrocq wrote:
> 
> 
> On Fri, Sep 19, 2014 at 6:13 AM, Daniel Micay  <mailto:danielmi...@gmail.com>> wrote:
> 
> On 19/09/14 12:09 AM, Lee Wei Yen wrote:
> > Hi all!
> >
> > I’ve just started learning to use Rust now, and so far it’s been
> > everything I wanted in a language.
> >
> > I saw from the docs that the num::bigint::BigInt type has been
> > deprecated - does it have a replacement?
> >
> > --
> > Lee Wei Yen
> 
> It was moved to https://github.com/rust-lang/num
> 
> There's also https://github.com/thestinger/rust-gmp which binds to GMP.
> 
> GMP has better time complexity for the operations, significantly faster
> constant factors (10-20x for some operations) and more functionality.
> 
> It also doesn't have lots of showstopper bugs since it's a mature
> library.
> 
> 
> Disclaimer, for the unwary, GMP is a GPL library; so using it implies
> complying with the GPL license.

Not true. It's under the LGPL license and proprietary applications can
both dynamically link and statically link against it. The end user needs
to be able to replace the library - which is a given with dynamic
linking, and can be done with static linking by providing linkable
object files rather than a binary (or both). Rust itself relies on
plenty of GPL with linking exception / LGPL code like glibc / libgcc /
libunwind.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Rust BigInt

[Daniel Micay]

On 19/09/14 12:09 AM, Lee Wei Yen wrote:
> Hi all!
> 
> I’ve just started learning to use Rust now, and so far it’s been
> everything I wanted in a language. 
> 
> I saw from the docs that the num::bigint::BigInt type has been
> deprecated - does it have a replacement?
> 
> -- 
> Lee Wei Yen

It was moved to https://github.com/rust-lang/num

There's also https://github.com/thestinger/rust-gmp which binds to GMP.

GMP has better time complexity for the operations, significantly faster
constant factors (10-20x for some operations) and more functionality.

It also doesn't have lots of showstopper bugs since it's a mature library.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Arbitrary-precision arithmetic

[Daniel Micay]

On 01/09/14 08:51 AM, Cody Mack wrote:
> Hi,
> 
> Regarding issue #8937 (https://github.com/rust-lang/rust/issues/8937),
> add a BigDecimal type, there is discussion about wrapping GMP, and
> even possibly replacing Rust's current BigInt with this wrapper. One
> comment mentions that Rust's current BigInt is ~100x slower than GMP
> in some cases. However, GMP is licensed under LGPL.
> 
> 1. Are there benchmarks displayed somewhere for comparison of BigInt
> vs. GMP? It would be helpful to know cases from where the factor 100x
> came.

Rust's BigInt has progressively more inferior *time complexity* as the
numbers get bigger. It's far worse than 100x for very large numbers.

It's significantly slower for relatively small numbers because it lacks
years of work writing optimized assembly. This gets more important as
domain specific instructions like MULX are added to CPUs, along with
more diverse SIMD instructions with wider registers. Auto-vectorization
doesn't work for complex cases like this.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] By-value variable captures landing soon

[Daniel Micay]

On 19/08/14 04:39 PM, Evan G wrote:
> Is there a way to capture some variables by-value, and others
> by-reference? The 'ref' syntax you talked about seemed to be only for
> the whole argument list, but I might have misunderstood.

You can capture references by-value, because they're normal values. The
`ref` syntax is sugar for a common case.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Accessing Rustup.sh Securely

[Daniel Micay]

On 03/08/14 03:04 PM, Bryce Fisher-Fleig wrote:
> Dear RustLangers,
> 
> TL;DR::
> Only access rustup.sh at
> https://raw.githubusercontent.com/rust-lang/rust-www/gh-pages/rustup.sh
> and NOT at www.rust-lang.org .
> 
> Full Story::
> If you're like me, you love the convenience of getting the lastest
> version of the rust compiler and cargo updated via rustup.sh. However,
> this script is delivered insecurely over HTTP.
> 
> HTTP by itself provides no guarrantees that the content sent by the
> server is the same as content received by client. Eric Butler created a
> firefox extension called Firesheep that allows you to hijack any
> insecure session cookies available on any computer on the wifi network
> [http://codebutler.com/firesheep/]. Joel Weinberger of the Google Chrome
> security team recently explained how any content delivered over HTTP can
> be changed by a malicious or compromised router between you and the
> server [https://www.youtube.com/watch?v=X1ZFjOZMSQg].
> 
> Why is this a problem for rustup.sh? Because we're encouraged to curl
> rustup.sh and pipe the result to sudo. The problem is that an infected
> or compromised router could insert malware into rustup.sh and run that
> code as root. Now you no longer own your computer.
> 
> What's the fix? ONLY ACCESS RUSTUP.SH OVER HTTPS. HTTPS more-or-less
> guarrantees that the content sent from the server is what is delivered
> to the client. Fortunately, github delivers all it's content securely
> over HTTPS. You can have a high degree of confidence by simply accessing
> rustup.sh from
> https://raw.githubusercontent.com/rust-lang/rust-www/gh-pages/rustup.sh
> 
> Why don't the maintainers of www.rust-lang.org
>  deliver all the content over HTTPS?
> www.rust-lang.org  is hosted using GithubPages
> on a custom domain. Unfortunately, GithubPages doesn't allow HTTPS for
> custom domains, which is a pity. However, by using GithubPages any pull
> requests merged into the repo are immediately reflected on
> www.rust-lang.org . Also, GithubPages provides
> DDOS protection and is provided free of charge to open source projects
> like Rust. So, all things considered, this seems like the best course of
> action currently.
> 
> Cheers,
> Bryce

That's not going to help because you're still downloading the compiler
snapshots over HTTP.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] std::num::pow() is inadequate / language concepts

[Daniel Micay]

On 26/07/14 12:56 PM, Patrick Walton wrote:
> On 7/26/14 5:54 AM, SiegeLordEx wrote:
>> While this doesn't matter for the pow function (the alternate function
>> would just have a different path/name), it matters for the special
>> syntaxes. When the Iterator is no longer enough for you (there was a
>> case like this in IRC recently involving mutable windows), then you have
>> to abandon the for loop which is a big syntactic change (right now it
>> works because it is ad-hoc).
> 
> As of last week it's not anymore.
> 
>> Similarly, when the operator overloading
>> traits are insufficient, then you have to abandon that sugar as well.
>> One might say "well, don't use those traits then" but that's not what
>> happens in practice. In practice, people want the syntax sugar and
>> therefore are guided into inefficiency. Some of BigNum's operator
>> overloads shouldn't exist because they are so inefficient, and yet they
>> do because people expect BigNum to act (on a syntactic level) just like
>> any other number.
>>
>> So I think this is a real problem with real solutions that don't require
>> going down the ad-hoc template black hole.
> 
> Well, part of the problem here is that people are going to want to write
> generic functions that take addable values. If we start making `+` and
> friends overloadable/ad-hoc, then people are going to be surprised when
> they can't pass (say) bignums to functions that want addable things.
> 
> Patrick

We can start out with efficient generic code for bignums (meaning stuff
like `op(&mut tmp, &a, &b)` in a loop with a reused temporary variable)
and then add a "static" branch + other code for primitives as vector
iterators already do for zero-size types. Ideally there would be a way
of expressing it without relying on optimizations to remove a branch but
the language is expressive enough other than that.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Implementation of traits in Rust: could it be dynamic?

[Daniel Micay]

On 24/07/14 11:59 AM, Lionel Parreaux wrote:
>
> I can't pronounce myself about the suitability of features in the Rust
> language, but it may be worth noting that some convenient high-level
> features are already present in the language, like garbage collection.

There isn't an implementation of garbage collection.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] C++ to Rust - Is that about right?

[Daniel Micay]

On 14/07/14 03:33 PM, Robin Kruppe wrote:
> 
> Second, the signature of MyClass::new() in your example is... unusual.
> The return type unnecessarily narrow (returns a trait object instead of
> the concrete type, even though callers have to know the concrete type
> anyway to call new()) and does a pointless allocation as a consequence.
> Just return a MyClass by value. If the call site needs polymorphism,
> it's trivial to add (box MyClass::new() as Box) and more
> flexible (can use different smart pointers, or a borrowed reference for
> short-lived uses). If there are numerous call sites and they all need
> need trait objects, your design MAY be overly polymorphism-oriented for
> the taste of Rustaceans.

The trait object also results in dynamic dispatch and indirect access to
the object, in addition to the memory allocation.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] C++ to Rust - Is that about right?

[Daniel Micay]

On 14/07/14 02:45 PM, Christoph Husse wrote:
> 
> Now I can hear the screams already :D. So I want to explain a bit
> about this choice.
> 
> First, I find the rust source code I looked at so far pretty
> unstructured and confusing. Everything seems to be defined somewhere
> at will, without having a real concept (or I am just blind to see it).
> 
> I think it is annoying to put exported types into submodules, because
> this will create a "use" nightmare. It is equally annoying to have
> those huge files as many rust projects have atm, by defining AND
> implementing various types in the same module.

You don't need your weird trait usage to do this... just put all of the
implementations into private submodules if you want smaller files. It's
a style choice and shouldn't be exposed to library users.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Impending change in RPATH behavior when linking to Rust dynamic libraries

[Daniel Micay]

On 11/07/14 03:15 PM, Alex Crichton wrote:
>> LD_LIBRARY_PATH is not known about by many
> 
> The install.sh script now recommends adding an entry to this variable
> if it detects that this is necessary, so it's not *entirely* unknown.
> This doesn't help, however, if it's considered a bad practice.
> 
>> 1) Link dependencies of rustc statically to it?
> 
> For plugins to work, we're required to link libstd and friends
> dynamically to rustc, so sadly we're require to link rustc itself
> dynamically.
> 
>> 2) On Windows the folder of the executable is always searched for
>> dependencies. Is this the case on Linux too? Then you could just let 'make
>> install' copy everything next to rustc.
> 
> I do not believe that this is this case for linux or OSX, only for windows.

It's not acceptable to dump a bunch of libraries in /usr/bin or
/usr/local/bin anyway.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] robots.txt prevents Archive.org from storing old documentation

[Daniel Micay]

On 10/07/14 03:46 AM, Gioele Barabucci wrote:
> Hi,
> 
> the current robots.txt on docs.rust-lang.org prevents Archive.org from
> storing copies of the old documentation. I think having the old
> documentation archived would be a good thing. BTW, all the documentation
> before 0.10 seems gone and this is a shame.
> 
> Could you please allow the Archive.org bot to index the site?
> 
> For the records:
> 
> $ curl http://doc.rust-lang.org/robots.txt
> User-agent: *
> Disallow: /0.3/
> Disallow: /0.4/
> Disallow: /0.5/
> Disallow: /0.6/
> Disallow: /0.7/
> Disallow: /0.8/
> Disallow: /0.9/
> Disallow: /0.10/

The old documentation is all available from the Git repository. The
robots.txt rule is there to reverse the trend of searches being filled
with out of date documentation.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 27/06/14 01:45 AM, Gregory Maxwell wrote:
> 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 will be avoided.
> 
> Checked integer operation during tests would potentially have detected
> this even where the tests were not quite good enough to usefully
> trigger the out of bounds memory access, even given your argument that
> the tests would be off in production.
> 
> (We had bugs like that in the development of the opus specification
> which were detected by Regehr's interger overflow checker but didn't
> trigger valgrind for inputs probable enough for the fuzzer to reach.)

If you had actually written a test to pass >16M of zeroes to it on
32-bit, and terabytes of data on 64-bit. It wouldn't have ever been
caught on 64-bit hardware.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 27/06/14 01:38 AM, Tony Arcieri wrote:
> On Thu, Jun 26, 2014 at 10:30 PM, Daniel Micay  <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
> not going to use checked arithmetic types. Every branch that the
> programmer thinks can be avoided will be avoided.
> 
> 
> I know you're not fans of a compiler flag, but a checked debug build
> with traps you can optimize out in an optimized build could've caught it.
> 
> As it were, this is what Swift provides (in addition to explicit
> overflow operators) 

It doesn't happen on inputs that aren't pathological, a debug build with
checked overflow wouldn't have caught this. No one had considered this
issue and there was no test for it.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 micro-optimization are
not going to use checked arithmetic types. Every branch that the
programmer thinks can be avoided will be avoided.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 and non-wrapping calculations in the
> same scope?).

You can also wrap a single operation in a block, like `let z =
#[wrap(no)] { x + y }`. Rust just needs to start accepting attributes on
blocks.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 and non-wrapping calculations in the
> same scope?).

Introducing new types would make the language more painful to use, and
it would be difficult to determine the correct types to use at API
boundaries. It would be a large backwards compatibility hazard among
other issues, and would introduce performance overhead due to issues
like `&[u32]` and `&[u32c]` being different types.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 anyone but myself.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] [ANN] Initial Alpha of Cargo

[Daniel Micay]

On 24/06/14 03:06 PM, Erick Tryzelaar wrote:
> I've been (very slowly) working on a pure rust build system
> (https://github.com/erickt/rbuild) that we might be able to someday use
> to do complex builds without needing other external language or build
> system.

Well, +1 for that because it's very cool. However, I don't see a problem
with depending on tooling like `make` in a portable library.

In my opinion, the only sane way to do Rust development on Windows is
via msys2. You get a sane development environment with a reasonable
terminal and shell, along with a nice package manager for updating the
whole thing along with installing / upgrading many libraries / tools
from the msys2 repositories. It also makes it trivial to install tools
like gdb, make, sed or python.

Otherwise, you'll have the hopeless struggle of manually building
tooling / libraries and dealing with upgrades / rebuilds yourself rather
than through a package manager.

The important part is for the produced binaries to be standalone, and
mingw-w64 provides that. The only major weakness is the lack of
compatibility with Windows C++ headers and the C++ ABI, although there
is ongoing work towards providing that. Rust can't call into C++
directly anyway, so it's not an enormous obstacle.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 always going to be
> acceptable, so the feature has next to no value in terms of memory safety.

s/acceptable/unacceptable/



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 24/06/14 02:51 PM, Gregory Maxwell wrote:
> 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
> code cannot express where integer overflow is correct or incorrect has
> no place in 2014. Even C does better than this."

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
audited it (just as you would an `unsafe` block) and determined that it
can not overflow. This doesn't introduce implementation defined
behaviour or new language dialects via compiler flags.

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 itself.

> I don't really think such dramatic language is helpful. There are real
> tradeoffs in this space and some of them are mutually exclusive.
> Different people for rational reasons prioritize different criteria
> over each other, that doesn't make anyone wrong. There is no need to
> 'win' an argument, or even argue at all. Presumably everyone can hear
> ideas and preferences in this space without the discussion getting
> that intense.

Yes, there are real tradeoffs to make here. However, some people feel
the need to spread misinformation to back up their points and pretend to
compromise and address the issues raised by the other side while
ignoring them. It gives the appearance to someone not reading the whole
context of the thread that they have been addressed when in fact they
have not.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 24/06/14 11:12 AM, Gregory Maxwell wrote:
> 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 tackle the problem. If you can't depend on
>> the semantics then there's no reason to have the feature.
> 
> Because there are many places where the runtime cost is unacceptable—
> as you've pointed out yourself. But running tests and debug builds
> with that cost is seldom an unacceptable hit and can improve code
> quality a lot, plus static analysis can make use of the additional
> information.  But all of this is unworkable if the code is full of
> harmless overflows because overflow was a perfectly acceptable thing
> to do in all cases.
> 
> The behavior of non-checked non-wrapping types could be specified
> in-so-far as they _either_ wrap or fault, up to the implementation...
> and a checked{} block could force the latter.

A language full of implementation defined behaviour and language
dialects via compiler switches has no place in 2014.

A top-level `#![checked]` flag with the ability to turn it off in
performance critical scopes will work fine if the claims about compiler
optimization passes here are true. I don't see a reason to have a
compiler switch when most of the people who want this feature are so
certain that it can be made cheap.

>> Simply making it unspecified makes 0% of the operations checked because
> few people will ever pay the huge performance cost to enable them,
> 
> I would expect that virtually everyone would run enable them in
> testing/QA builds, and all static analysis tools would make use of the
> additional information (e.g. that if it can prove that some series of
> operations will cause an overflow, thats a bug).
> 
>> This proposal is just the same stuff that has already been proposed
> without any response to most of the issues raised by those on the other
> side of the fence
> 
> It seemed pretty clear to me that he was attempting to try to balance
> the concerns. Perhaps he failed, but you spent half your message
> dismissing his attempted compromises before saying he made none at
> all.

He wasn't trying to balance the concerns, he was presenting the same
proposal yet again and not addressing the concerns that have been
raised. There were no attempts at compromising, it's the same thing as
the other proposals but presented as if it's a compromise.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 24/06/14 10:57 AM, Lars Bergstrom wrote:
>> On Jun 23, 2014, at 7: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 making it clear that doing this by default would make Rust
>>> slower than Java by default, and I think that would kill off interest in
>>> the language. I know I wouldn't be interested anymore.
>>
>> Sure, I think there are a lot of reasonable options here, and I agree that 
>> speed and predictability are super important for Rust.
>>
>> One thing I personally think is very important (not for 1.0, but eventually) 
>> is to make it possible -- no need for this to be mandatory -- to get 
>> overflow checking for the default integer type.  I'm happy to use a special 
>> compiler flag or whatever to get this.  The only controversial thing this 
>> requires from the core language is a way for me to tell the compiler which 
>> integers (a tiny subset, typically) should have wrapping behavior.
> 
> If the compiler option to have integer overflow checking were available, I'm 
> 99% sure that we'd require having it enabled for Servo and all of its 
> dependencies. We would probably only relax that requirement within the 
> equivalent of an `unsafe` block where the performance had shown up as an 
> issue, leaving it clearly labeled so that we could easily identify any code 
> that touches it.

This has nothing to do with `unsafe`, considering it to be `unsafe`
would be incorrect. I doubt Servo would use it, because at that point I
don't understand why you wouldn't just be writing the browser in Scala
as it would perform better. There has been a strong consensus to avoid
jamming things unrelated to memory safety into `unsafe`, such as
catching reference cycles.

>> I realize that safe integers are available and that operator overloading 
>> goes a lot ways towards making these palatable, but 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.
> 
> At a quick glance, in Mozilla's bugzilla there were 88 public browser bugs 
> resolved/verified related to integer overflow issues + 14 currently under 
> investigation. I don't have access to the tippy-top secret databases of 
> security vulnerabilities, but I'd be pretty shocked if there weren't a few 
> that would get past Rust's memory safety model (e.g., because they're passed 
> down to WebCL, WebRTC libraries, a graphics driver, etc.). A quick glance at 
> the WebKit bugzilla showed 11 similarly resolved bugs and a couple currently 
> under investigation.

We've have very few memory safety bugs caused by integer overflow, and I
haven't seen these occur in places where the performance hit of the
integer overflow checking would have been acceptable.

The only one I can think of off the top of my head is the size overflow
in the ~[T] `push` function. The overflow check there had to be done
very carefully, as one check reduces the performance of pushing to a
vector by ~20% but adding in two checks resulted in a >200% loss in
performance. There are numerous calculations in that function, so
automatic integer overflow checking would destroy it.

On the other hand, we've had countless memory safety bugs caused by
exceptions. The difficulty of writing exception safe code is high, and
it's likely the most common safety issue in the Rust codebase. Yet I
don't see the Servo developers arguing against having exceptions in
Rust, in fact they're the strongest supporters of the feature.

> While that isn't a lot, if I have to choose between the Servo team spending 
> time casually optimizing corner cases or adding an LLVM pass (in ways we 
> already know - this isn't "A Sufficiently Smart Compiler"-level hackery here) 
> vs. handling panicked high-priority security issues in a browser we are 
> trying to claim is "safe," I'll pick the former every time.

You can continue living in your fantasy world, but in the real world no
compiler pass is going to make a language with overflow checking perform
as well as Java/Scala. You can keep repeating this misinformation, but
it doesn't make it any more true.

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 always going to be
acceptable, so the feature has next to no value in terms of memory safety.

It would help in identifying correctness issues in other cases, but it
wouldn't actually be any more correct to throw an exception than to
overflow. In either case, it's a bug, and in neither case is it a memory
safety issue.



signature.asc
Description: OpenPGP digital signature
_

Re: [rust-dev] [ANN] Initial Alpha of Cargo

[Daniel Micay]

On 24/06/14 12:15 PM, Diggory Hardy wrote:
> Using Go (or Python or whatever) for this implies either the build
> system needs to include compiled binaries (not good) or the system doing
> the build needs to have a Go (or xyz) interpreter installed. So
> cross-platform build configurations will require an external dependency
> (or writing separate scripts for each target platform) if external
> scripts are used.

Yeah, it makes absolutely no sense to use Go for this. It would have no
advantage over using Rust for this task and would add an unnecessary
dependency along with requiring people to learn another language...



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 24/06/14 01:55 AM, Jerry Morrison wrote:
> 
> 
> On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay  <mailto: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 possible to alter the
> behaviour of functions in general because of crates. It would also be
> incorrect if they required wrapping semantics.
> 
> > One detail: There should be a way to explicitly specify
> > wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint
> would
> > never complain about that.
> 
> I think the scope-based solution would probably be cleaner in that case:
> 
> #[checked]
> fn foo() { ... }
> 
> #[unchecked]
> fn bar() { #[checked] { ... }  }
> 
> The lint would warn for operations in a scope without an explicit
> decision one way or the other. You could even put `#[checked]` at module
> / crate level and override it in inner scopes.
> 
> I think that's as a sane solution, as opposed to introducing dialects
> with compiler switches which I really dislike.
> 
> 
> Attributes do seem saner than compiler switches.
> 
> Intentional-wraparound arithmetic is different than
> unchecked-for-speed-and-lint-could-complain, and probably only applies
> to fixed sized, unsigned integers. Would you use wraparound operators
> like &+ for those?

Well, perhaps a better naming convention is `#[wrapping(no)]` (with
checks) and `#[wrapping(yes)]`. I don't really like the idea of having
language support for a no-op convention.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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  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 indentation.
> 
> I think it would actually work best as a lint-like attribute you could
> apply at any item level or to a block. It would flip the behaviour of
> the operators for that scope, and you could override it any number of
> times in inner scopes.

By 'flip' I mean *override*, you'd have both #[checked] and
#[unchecked], although preferably with clearer names.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 24/06/14 01:22 AM, comex wrote:
> On Tue, Jun 24, 2014 at 1:17 AM, Jerry Morrison  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 indentation.

I think it would actually work best as a lint-like attribute you could
apply at any item level or to a block. It would flip the behaviour of
the operators for that scope, and you could override it any number of
times in inner scopes.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 possible to alter the
behaviour of functions in general because of crates. It would also be
incorrect if they required wrapping semantics.

> One detail: There should be a way to explicitly specify
> wraparound-arithmetic, e.g. wraparound-arithmetic operators. Lint would
> never complain about that.

I think the scope-based solution would probably be cleaner in that case:

#[checked]
fn foo() { ... }

#[unchecked]
fn bar() { #[checked] { ... }  }

The lint would warn for operations in a scope without an explicit
decision one way or the other. You could even put `#[checked]` at module
/ crate level and override it in inner scopes.

I think that's as a sane solution, as opposed to introducing dialects
with compiler switches which I really dislike.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 easier... or so on...
> 
> What about:
>  - Defining "safe" integer in Rust with strict and well defined rules.
>  - Enforcing the rules is an incremental process.
> 
> At first, Rust will not enforce any rules, maybe in debug mode or what
> not for who wants to pay the cost. One could add an attribute on
> blocks to enforce runtime overflow check at all cost, when you really,
> really need safety no matter the speed tradeoff. And in the future,
> the compiler & standard library are free to effectively enforce more
> of the rules, as performances tradeoff mitigate.
> 
> Its kinda like when C/C++ compiler started warning that not all cases
> where handled in switch/cases on enums (yes I know our case is
> different on many level).
> 
> What is important, is that the rules of the different safe integer
> types are well defined, even if not necessarily enforced yet.
> 
> If you think about it, its better than nothing.
> 
> The goal is not to solve everything right now, but at least to define
> the scope of the problem when it is still possible, before everybody
> uses "unsafe integers", so it can be implemented in the future.

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 tackle the problem. If you can't depend on
the semantics then there's no reason to have the feature.

Simply making it unspecified makes 0% of the operations checked because
few people will ever pay the huge performance cost to enable them, while
adding usable checked arithmetic would actually be valuable.

This proposal is just the same stuff that has already been proposed
without any response to most of the issues raised by those on the other
side of the fence. It's introducing unspecified behehaviour / language
dialects, the problems associated with fragmenting code into various
integer types, and the other issues that were raised. This seems
strictly worse than an operator or scope-based solution to me.

Increasing the complexity of the language with no clear goals is not
"better than nothing". It's not somehow going to become 'free' in the
near future, and there's no point in trying to design for 25 years down
the road at the expense of making it worse today.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 making it clear that doing this by default would make Rust
>> slower than Java by default, and I think that would kill off interest in
>> the language. I know I wouldn't be interested anymore.
> 
> Sure, I think there are a lot of reasonable options here, and I agree
> that speed and predictability are super important for Rust.
> 
> One thing I personally think is very important (not for 1.0, but
> eventually) is to make it possible -- no need for this to be mandatory
> -- to get overflow checking for the default integer type.  I'm happy to
> use a special compiler flag or whatever to get this.  The only
> controversial thing this requires from the core language is a way for me
> to tell the compiler which integers (a tiny subset, typically) should
> have wrapping behavior.
> 
> I realize that safe integers are available and that operator overloading
> goes a lot ways towards making these palatable, but 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.
> 
> Finally, I'll note that certain optimizations such as array bounds check
> removal and some loop optimziations actually get better then integers
> cannot wrap.  Clearly we would not expect, in general, for these
> benefits to make up for the costs of overflow checking.

They'll get better if they're simply guaranteed not to wrap, but not if
there are checks enforcing that at runtime. It can only get worse with
runtime enforcement. LLVM becomes unable to hoist out a bounds check in
many cases if there's a separate failure path for overflow checking.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 06:34 PM, comex wrote:
> On Mon, Jun 23, 2014 at 5:38 PM, Benjamin Striegel
>  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. Regardless of
>> Swift's implementation or design decisions, it *will* be one of the most
>> popular languages in the world come this time next year (likely accompanied
>> by Objective-C's meteoric descent). If Swift were a fusion of RPG and
>> Malbolge with an implementation written in INTERCAL, this fact would not
>> change (thankfully, the Swift designers have better taste). Why bother
>> straining yourself to satisfy a captive audience, when your only real
>> competitor is whatever dialect of Java that Dalvik supports?
> 
> For one thing, Swift ought to be an appealing potential competitor for
> Apple's internal high-performance frameworks, which are currently all
> C++.

Perhaps with the -Ofast hack...



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 06:08 PM, Tony Arcieri wrote:
> On Mon, Jun 23, 2014 at 3:07 PM, Daniel Micay  <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 high-level
> SIL IR layer if that's not where they plan on doing these optimizations.
> 
> To flip the question around: what's wrong with Swift's approach?

Nothing is wrong with performing optimizations on a high-level IR, it's
more realistic than doing it in LLVM IR. It adds complexity and hurts
compile-time, but it's a pragmatic approach. However, there are no plans
to have an optimization layer in Rust's frontend.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 05:57 PM, Tony Arcieri wrote:
> On Mon, Jun 23, 2014 at 2:44 PM, Daniel Micay  <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
> options I proposed are purely additive changes to Rust that would not
> affect at all how it works today, besides adding new functionality. I'm
> just proposing that the new functionality mirror what Swift is doing, so
> that optimizations that are added to LLVM by Apple/Swift can be
> leveraged by Rust too.
> 
> Make sense?

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.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 the C compiler their OS is built with,
> the Objective-C language that all their apps are written in, the IDE
> used to write those apps, and the Javascript engine that powers their
> web browser. Despite Swift's arrival, I wouldn't expect any greater
> investment in LLVM than Apple does currently (which is a shame, given
> the bazillion dollars burning a hole in their pocket).
> 
> 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.
> Regardless of Swift's implementation or design decisions, it *will* be
> one of the most popular languages in the world come this time next year
> (likely accompanied by Objective-C's meteoric descent). If Swift were a
> fusion of RPG and Malbolge with an implementation written in INTERCAL,
> this fact would not change (thankfully, the Swift designers have better
> taste). Why bother straining yourself to satisfy a captive audience,
> when your only real competitor is whatever dialect of Java that Dalvik
> supports?

Apple has also shown that they will keep their code proprietary to
maintain a competitive advantage. This is what they did with their
64-bit ARM backend, but eventually relented and landed it upstream
because the 'community' version was pulling ahead.

They have their own SIL IR for Swift, and doing these optimizations at
the SIL layer would be easier. It's harder to do these at a low-level
and they can simply sit back and benefit from those improvements without
giving away their own secret sauce. This is Apple we're talking about
after all... Objective-C was originally only open-source because it was
implemented on top of GCC and they were forced into it.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 05:08 PM, Tony Arcieri wrote:
> On Mon, Jun 23, 2014 at 1:32 PM, Daniel Micay  <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 that, but if the argument is to use Swift's approach, i.e.:
> 
> Non-overflow operators: + - * / %
> Overflow operators: &+ &- &* &/ &%
> 
> Or let's swap Swift's defaults if you so desire:
> 
> Overflow operators: + - * / %
> Non-overflow operators: &+ &- &* &/ &%
>  
> Or even change the syntax if you so desire:
> 
> Overflow operators: + - * / %
> Non-Overflow operators: +~ -~ *~ /~ %~
> 
> ...then any arguments about performance are really a false dichotomy.
> It's just a question of syntax and defaults. Want to perform well at
> TIOBE or other (micro)benchmarks? Use the overflow operators! Want to
> write safe code? Use the checked overflow operators. I really think Rust
> should support both approaches, be it implemented through a type or
> operator or what have you. I'm not here to bikeshed that. I just want to
> make sure both approaches have a first class position in the language,
> and would generally prefer but don't insist upon checked overflow being
> the default.
> 
> If the Rust developers insist on choosing overflow operators as the One
> True Way To Do Math, well, that's your prerogative. I will probably
> still choose Rust over Swift. But then I feel like Rust might be missing
> out on the free lunch I expect Swift to provide, which is sad if that's
> the way the cookie crumbles...

Rust is a performance-centric systems language, Swift is not. The
language chooses performance above other considerations like complexity
(move semantics, lifetimes, large APIs) and correctness elsewhere. It
has memory safety in safe code as a hard requirement, but anything else
is missing the point of the language.

An opt-in lint works well for catching accidental usage of the unchecked
operators, but it doesn't work well for catching accidental usage of the
checked ones. The one with the normal math syntax is the 'default' and
is the one that people are going to use when not specifically thinking
about it.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 inner loops are only 10-30% slower
than C, so Rust with checked overflow would be slower. It already has
the issue of bounds checks and checks on the arithmetic leading up to
the bounds checks would make it even harder to hoist these out of loops.

>> I don't understand what the problem would be with my proposal to have
>> either `checked { }` or checked operators + a lint for unchecked usage.
> 
> My /own/ desire there doesn't even want either of those things, though
> I agree they could also be useful.
> 
> With the performance concerns aside, my reason for commenting was
> wanting the programmers intention to be well specified enough in
> widely deployed software that strong static and debug-build dynamic
> checking are able to suss out all aspects of software correctness, not
> just memory safety.
> 
> I think it will be unfortunate if rust takes a step back from C by
> resulting in an ecosystem where common idiomatic rust code is less
> amenability to tools that help software authors find incorrect code by
> reasoning from or trapping on overflow behavior.

The need to distinguish between wrapping as a bug and wrapping as an
error case would make Rust more difficult to write. I can see the
appeal, but I don't think it's worth the cost. I think Rust is already
pushing the complexity / noise limit that people will tolerate just to
achieve memory safety without losing references as values or using a
garbage collector, so I'm generally against adding more pain for the
sake of catching regular bugs.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 won't
> be slower than JavaScript, since JS needs the overflow checks too. :)
> (And engine implementers; e.g. Vyacheslav Egorov, have noted that
> they're a performance problem in JS.)
> 
> Patrick

I'll go with Scala (and Java) as my point of comparison then :P.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 03:59 PM, Cameron Zwarich wrote:
> On Jun 22, 2014, at 4:12 PM, Patrick Walton  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 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 program correctness are not?
>>>
>>> I am wary of circling around on this topic again, but I feel that the
>>> biggest mistake in this discussion js that checked overflow in a
>>> language requires a potential trap on every single integer operation.
>>> Languages like Ada (and Swift, to a lesser extent), allow for slightly
>>> imprecise exceptions in the case of integer overflow.
>>
>> I believe that it is possible that the overhead of integer overflow will be 
>> negligible in the future, and that paper is exciting to me too! But I feel 
>> that:
>>
>> 1. Integer overflow is primarily a security concern when it compromises 
>> memory safety. Quoting OWASP [1], emphasis mine:
>>
>> "An integer overflow condition exists when an integer, which has not been 
>> properly sanity checked, is used in the *determination of an offset or size 
>> for memory allocation, copying, concatenation, or similarly*.”
> 
> It doesn’t sound like that definition would consider this bug an “integer 
> overflow condition”, but it certainly seems like one to me:
> 
> http://minimaxir.com/2013/05/stones-of-jordan/

Rust's usage of `unsafe` is restricted to low-level performance critical
code and wrapping existing C libraries. I doubt that checked overflow is
going to be used in the former case since it's performance critical code
at the core of the standard libraries and in the latter case it's up to
the C code to get it right.

>> 3. The As-If-Infinitely-Ranged paper is research. Like all research, the 
>> risk of adopting integer overflow checks is somewhat high; it might still 
>> not work out to be acceptable in practice when we've exhausted all potential 
>> compiler optimizations that it allows. That risk has to be compared against 
>> the potential reward, which is likely to be lesser in Rust than in C because 
>> of the reasons outlined in (1) and (2).
> 
> Ada adopted a similar model before many of the people working on Rust were 
> even born, so the basic idea isn’t research. The researchy aspect of the AIR 
> paper is retroactively applying it to C. There are probably some unanswered 
> questions regarding aggressive optimizations in the face of this model, but 
> the same goes for many other design choices of Rust.
> 
>> 5. It's not clear to me that integer overflow cannot be added backwards 
>> compatibly: we can lexically scope checked arithmetic in much the same way 
>> C# lexically scopes unchecked arithmetic. It's not in line with Rust's 
>> philosophy of safe-by-default, but saying that we might introduce a safer 
>> opt-in version of Rust in the future strikes me as a fairly pragmatic 
>> compromise, and one that is not without successful precedent: for example, 
>> C, has, for all intents and purposes, successfully shed the baggage of its 
>> "variables without an annotated type default to int" design mistake via a 
>> bog-standard compiler warning.
> 
> I had to deal with bugs caused by K&R C last year, and ABIs for new 
> architectures like ARM64 are designed to be compatible with K&R C, even if it 
> complicates the implementation, so I don’t necessarily agree that the removal 
> of baggage has been quick.
> 
> We can probably correct integer operations later (even if it breaks backwards 
> compatibility to some extent), but it’s disappointing that a systems language 
> from ~2013 can’t learn from all of the correctness lessons of a systems 
> language from 1983.

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 don't see why having either `checked { }` or explicitly checked
operators along with a lint is a problem. It will be backwards
compatible and won't interfere with the out-of-the-box performance, and
there won't be any significant drawbacks for people who want the feature.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 04:00 PM, Gregory Maxwell wrote:
> 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't make sense to just check for that.
> 
> The undefinedness of just signed overflow in C has shown itself to be
> useful from a performance perspective and, paradoxically now that
> better testing tools exist, from a correctness perspective.

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 signed overflow is reasonable small.

Undefined behaviour on overflow is also a memory safety issue, while
wrapping on overflow is not. You can claim that it could cause memory
safety issues via incorrect unsafe code, but low-level code is going to
be using wrapping or undefined semantics for performance regardless of
the default.

> I think a lot the discussion here has been about having checked types
> and making them a default, not in forcing all possible usage into
> them.  If only making the signed type checked had much better
> performance characteristics  then it ought to be considered.

Slower performance than Java by default would kill off nearly all
interest in Rust, and would make the claim that it's a viable C
replacement even less true than it already is.

I don't understand what the problem would be with my proposal to have
either `checked { }` or checked operators + a lint for unchecked usage.

> John was kind enough to post numbers for each of many microbenchmarks
> instead of a range. Beyond the signed vs signed+unsigned do you have
> any additional idea why his numbers would be lower than yours?

If you read my response, you'll see that I mentioned the impact of the
architecture on the results. I also mentioned that the code bloat issue
does not impact microbenchmarks as they fit entirely into the L1 cache
with or without the overflow checks. If we're going to play the game of
picking and choosing benchmarks, I can demonstrate cases where the
overhead is 1000-2000%.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 IR, not at the LLVM IR
>> layer where most of the information is already lost.
> 
> No, the overflow checks in Swift will turn into LLVM intrinsics such as
> llvm.sadd.with.overflow.  This is also what Rust would use.  Then, the
> IR-level optimizations will try to remove these.  LLVM already has a
> not-great integer range analysis that could be beefed up significantly
> without a whole lot of trouble.

I already exposed these intrinsics as Rust intrinsics and you can make a
user-defined integer type using these for the overloaded operators.

> Of course there's nothing stopping higher-level analyses from also
> attempting to avoid unnecessary overflow checks but I doubt that much or
> any of this is being done.

I don't think they'd have their own high-level IR if they didn't plan on
doing those kinds of optimizations. It's a compile-time hit so it's
there for a reason, and the only reasons I can think of are leveraging
the type system's design to eliminate bounds checks, overflow checks and
to perform devirtualization.

>> Rust 1.0 will be released in about 6 months, and these improvements
>> aren't going to happen in that time. It's a language for the present,
>> not one written for a fantasy architecture / compiler backend in 2025.
> 
> I wasn't arguing that Rust 1.0 should trap on integer overflow, I was
> arguing that the overhead of overflow checking isn't as high as you say.
>  But I'd be happy to look at real data.

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 making it clear that doing this by default would make Rust
slower than Java by default, and I think that would kill off interest in
the language. I know I wouldn't be interested anymore.

This conversation could just as easily be about using compiler
optimizations instead of exposing move semantics and lifetimes in the
type system.

Affine types and region typing is a lot of complexity to tackle an issue
that many people would claim a compiler could do. I don't see a claim
that it can eliminate the overhead of integer overflow checks or bounds
checks to be any less extraordinary, as if it was really as easy as
people are making it out to be then it would already work after all
these years.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 04:10 PM, Tony Arcieri wrote:
> On Monday, June 23, 2014, Daniel Micay  <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 hate to keep throwing hypotheticals at you, but here's another one:
> what if Apple invests in LLVM development which improves the performance
> of Swift semantics?
> 
> To be clear, Swift semantics eschew the dichotomy of checked overflow vs
> the fast path. Swift offers both, but makes the "safe" operators the
> default.
> 
> With safe operators as the default, and Swift being marketed as a
> performance-oriented language, Apple is incentivized to optimize Swift's
> overflow handling for performance. They have the resources, expertise,
> and connections to make these sorts of changes to LLVM.
> 
> I know it's a gamble, but if you "borrowed" Swift's semantics, wouldn't
> you potentially reap a free lunch from what Apple contributes upstream
> to LLVM to better optimize Swift?
> 
> I don't have the crystal ball. Maybe Apple won't submit anything
> upstream to LLVM in this regard. Maybe Swift will be a dud.
> 
> But if Swift succeds, and Rust were to adopt similar semantics, and
> Apple were to submit its LLVM optimizations for this upstream, I feel
> like Rust could reap many of the benefits too.

Swift isn't aimed at the same niche as Rust. It doesn't have references
at values, and you can't take references into values or arbitrary other
parts of data. It only has value types and atomically reference counted
reference types. It's in the same tier as C#, and isn't trying to
compete with the performance of C++ code.

It would be an enormous mistake to ship a language with region typing /
move semantics and worse before than Java. I can't see a language like
that succeeding at all. If you want Swift, feel free to use Swift.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 03:15 PM, John Regehr wrote:
>> Using checked overflow will
>> reduce the performance of most code with non-trivial usage of integer
>> arithmetic by 30-70%.
> 
> No, this view is overly pessimistic.

My numbers are based on real measurements, and are accurate. You can
pick and choose different benchmarks where the performance hit isn't as
bad, but it doesn't make my numbers overly pessimistic. The performance
hit will depend a lot on the architecture, and microbenchmarks can't
measure the cost of the bloated code because it will all fit in the L1
cache regardless.

> The last time we checked, Clang with the integer sanitizer turned on had
> a little less than 30% overhead for SPEC CINT 2006, on average.  Here
> are the actual slowdowns:
> 
>   400.perlbench   42.8%
>   401.bzip2   44.4%
>   403.gcc 12.7%
>   429.mcf 11.3%
>   445.gobmk   42.0%
>   456.hmmer   36.5%
>   458.sjeng   36.7%
>   462.libquantum  36.9%
>   464.h264ref 122.0%
>   471.omnetpp 4.8%
>   473.astar   16.1%
>   483.xalancbmk   12.4%
>   433.milc22.7%
>   444.namd15.5%
>   447.dealII  52.5%
>   450.soplex  17.5%
>   453.povray  11.0%
>   470.lbm 13.3%
>   482.sphinx3 34.3%
> 
> This was on some sort of Core i7.

It will be significantly worse on ARM and older x86 CPUs. A modern x86
CPU eliminates much of the overhead from the branches themselves, but
ARM CPUs are much worse at this and there are plenty of in-order CPUs
without the ability to do this at all.

Another issue is that even with checked arithmetic provided by the
architecture, Rust couldn't produce code with those instructions by
default because it targets the baseline architecture.

> Now consider that:
> 
> - This isn't only checking for signed overflows, it's checking for lossy
> casts, shift past bitwidth, etc. -- the average overhead goes down to
> 20% if we only check for C/C++ undefined behaviors

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't make sense to just check for that.

> - LLVM does a crap job in removing overflow checks; there's a ton of
> room for improvement, and I believe this will start happening now due to
> Swift

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 IR, not at the LLVM IR
layer where most of the information is already lost.

Rust 1.0 will be released in about 6 months, and these improvements
aren't going to happen in that time. It's a language for the present,
not one written for a fantasy architecture / compiler backend in 2025.

It's not going to be the last programming language, and hurting it in
the present based on biased predictions of the future is only going to
result in no one using the language.

If there was really a ton of low-hanging fruit, I expect it would have
been significantly improved by now. A claim that there's a lot of room
for improvement isn't worth anything. A working implementation is the
only thing that matters, and it needs to retain the good compile-time.

> - We designed the integer sanitizer to be a debugger, not a production
> tool, it has precise exception semantics which suppresses a lot of
> integer optimizations; a more relaxed exception model like AIR/Ada would
> permit most of LLVM's integer optimizations to keep working

I don't believe that LLVM will be capable of optimizing away most of the
overhead either way. LLVM is pretty much just an inlining machine with
good x86 code generation and register allocation. It isn't even capable
of eliminating a null check when the proof that it's null is in another
basic block because the value propagation is so incredibly bad.

The optimization capabilities of LLVM are greatly exaggerated. There's
essentially no interprocedural optimization or non-trivial alias
analysis, and it's next to impossible to preserve the high level type
system invariants.

We've made the mistake of making assumptions about LLVM's capabilities
before, by depending on optimizations that are actually implemented
(unlike the ones discussed here) but don't work in edge cases. Those
edge cases are surprisingly common, and Rust is often significantly
slower than C because some of the basic abstractions like iterators
depend on reasonable value propagation.

Rust is not a language designed for an imaginary sufficiently smart
compiler. It targets real architectures and the real LLVM backend. The
only numbers that matter are the ones you can measure, and those numbers
aren't going to drastically change in the 6 months before the 1.0 relea

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 programming not every line is going to be critical for
> performance. There is still going to be a distribution of some lines
> just taking more time than others. Additionally, in a single project,
> there's a nontrivial cost in using Rust for the 20% of code that's fast
> and using some other language for the remaining 80%. How are you going
> to transfer Rust's trait abstractions to, e.g., Python?

Rust's design rejects this kind of reasoning about performance not being
relevant to 80% of the code. The language forces you to deal with
ownership and lifetimes throughout the code, even though it's not going
to speed up most inner loops. It's there to improve the performance
characteristics if the language as a whole. If you don't care about
that, a high-level garbage collected language like F# is a better choice.

>> If you don't require absolute speed, why are you using Rust?
> 
> Because it's a nice, general purpose language? Systems programming
> language is a statement about capability, not a statement about the sole
> type of programming the language supports.

Rust supports checked overflow. It has operator overloading and
user-defined types.

> C++ can be and is used effectively in applications where speed is of the
> essence and in applications where speed doesn't matter. Is Rust going to
> be purposefully less generally useful than C++? There's always this talk
> of "C++ programmers won't use Rust because of reason X". Which C++
> programmers? In my experience the vast majority of C++ programmers don't
> push C++ to its performance limits. Are they using the wrong language
> for the job? I don't think so as there are many reasons to use C++
> beside its speed potential.

If you're using C++ and you don't care about performance or code size,
then you're using the wrong tool for the job. C++ doesn't have support
for checked overflow anyway, and there's a significant difference
between pushing the language to the performance limit and opting into a
50% performance hit. Checked overflow turns an overflow bug where the
program continues running into the program exiting abnormally, so it's
still a bug either way. We're not talking about a situation where
performance is being lost for the sake of correctness.

> Rust will never become popular if it caters to the tiny percentage of
> C++ users who care about the last few percent of speed while alienating
> everybody else (via language features or statements like yours). The
> better goal is a) enable both styles of programming b) make the
> super-fast style easy enough so that everybody uses it.

The two choices here aren't 'fast' and 'super-fast'. We're not talking
about the "last few percent of speed" here. Using checked overflow will
reduce the performance of most code with non-trivial usage of integer
arithmetic by 30-70%. The only saving grace is that many applications
use floating point arithmetic, and this would still be unchecked. Even
if the program is bounded by memory bandwidth, the stalls from all of
the extra icache churn are going to have an impact.

Supporting checked overflow well without changing the defaults is fine,
but that hasn't been what I've seen proposed here. I think Rust is
already providing a significant improvement over C by making signed
integer overflow defined, and we do pay in terms of some missed
optimizations from that alone. However, our pointer arithmetic was
switched to being inbounds like C, and you can often just use pointers
instead of relying on integer.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 01:16 AM, Cameron Zwarich wrote:
> On Jun 22, 2014, at 10:00 PM, Daniel Micay  <mailto:danielmi...@gmail.com>> wrote:
> 
>> On 23/06/14 12:49 AM, Cameron Zwarich wrote:
>>> On Jun 22, 2014, at 9:35 PM, Daniel Micay >> <mailto:danielmi...@gmail.com>
>>> <mailto: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 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.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 01:15 AM, comex wrote:
> On Mon, Jun 23, 2014 at 1:05 AM, Daniel Micay  wrote:
>> The call we make to perform unwinding isn't a pure function though, it's
>> aware of the context causing it to unwind. As long as we're supporting
>> stuff like backtraces outside of a debugger, that's going to be the case.
> 
> It does not seem essential to me that backtraces be 100% accurate in
> optimized builds - at least judging by how people manage to get by
> with the utter crap that is most compilers' optimized debugging info
> :P
> 
> Not sure exactly what you're referring to, though.

I'm referring the code performing failure in Rust being impure (not
readnone or readonly) in addition to being able to unwind (not nounwind).



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 12:46 AM, comex wrote:
> On Mon, Jun 23, 2014 at 12:35 AM, Daniel Micay  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.
> 
> No it doesn't!  Or maybe it does today, but an unwindable operation is
> guaranteed to be repeatable without consequence, which I'd like to
> think can account for most cases where operations are hoisted out of
> loops (again, could be wrong :), and not to modify any memory (unless
> it traps, but in Rust at that point you are guaranteed to be exiting
> the function immediately).

The call we make to perform unwinding isn't a pure function though, it's
aware of the context causing it to unwind. As long as we're supporting
stuff like backtraces outside of a debugger, that's going to be the case.

If it was pure beyond not being `nounwind` then LLVM would have more
freedom to move it around, but it would still cause more problems than
using `llvm.trap` (abort).

> In particular, the only reason I can see why an impure operation would
> require repeating a bounds check is if the compiler thinks it could
> modify the size of the array, or the index, or something else in
> memory.  But it cannot.
> 
> Yeah, yeah, Rust is designed for 2014 not 2024, and I admit "LLVM
> cannot do this right now" is a perfectly good reason in this context.
> But I want to differentiate the different arguments being made here.
>
>> Unwinding is a stateful effect, and any code that would be otherwise
>> pure is no longer pure if it has the potential to unwind. It's not
>> simply a matter of unwinding or not unwinding, the compiler needs to
>> ensure that the source of the unwinding is the same.
> 
> Only if it crosses initialization of objects with destructors.  It
> doesn't matter if the stack trace is off.
> 
>> I provided an example demonstrating the cost with `clang`.
> 
> First of all, that's including actual bounds checks as opposed to
> merely assuming impurity/unwinding, no?  Again, simply to
> differentiate the arguments...

It's just a measurement of the overflow checks on signed/unsigned
integers. It does introduce a form of impurity since it's aborting in
branches, but it's a simpler form of impurity than unwinding where the
code continues running based on the context where it was thrown.

> Second of all, it may be possible to do the checks more efficiently.
> I should look at clang's assembly output.

LLVM actually has intrinsics for checked arithmetic to avoid screwups in
code generation. I don't think it's going to get any better on x86 at a
code generation level.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 12:49 AM, Cameron Zwarich wrote:
> On Jun 22, 2014, at 9:35 PM, Daniel Micay  <mailto: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 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.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 23/06/14 12:17 AM, comex wrote:
> On Sun, Jun 22, 2014 at 5:05 PM, Daniel Micay  wrote:
>> Anyway, no one has offered an explanation of how they're
>> planning on integrating this into LLVM and how they propose turning a
>> trapping operation into unwinding across various platforms.
> 
> Isn't that what asynchronous unwind tables are for?  The actual
> platform glue isn't that difficult on the platforms I know of - at the
> cost of making interoperability with C programs that use signal
> handlers tend to break, but that's not fatal.

Asynchronous unwind tables are the low-level implementation detail for
providing this support. However, that doesn't mean it has well-defined
behaviour in LLVM IR. LLVM has modelling of effects like unwinding, and
it does assume that unwinding cannot simply occur anywhere. If it had to
make that assumption, it would be far less capable of performing
optimizations.

In the case of MPX, you could add new LLVM intrinsics and provide a hard
guarantee that whatever signal handler glue you use to turn MPX into
unwinding *never* occurs outside of those LLVM intrinsics.

> On Reddit you mentioned that unwinding impedes optimization.  But I'd
> still like to hear more specifics... what sort of optimizations?  I
> believe you if you say that simply allowing unwinding (without
> considering the cost of actually trapping*) significantly impedes
> performance today, but can some of that can be fixed?  In terms of
> true limitations, I can think of:

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.

> - No more speculative execution - 'foo ? x + 2 : y + 4' now must be a
> branch instead of a cmov.  But how common is this in practice?  'foo ?
> x + 2 : x + 4' can of course be done with a cmov.  Bigger statements
> turn into branches anyway in practice.
> 
> - Can't reorder arithmetic with respect to stores that could be
> visible to destructors.  Does it matter?  It's still fine to eliminate
> common subexpressions as long as they're only computed when one of
> their instances should be.
> 
> My intuition could be wildly off, but I don't see why this should be
> such a big deal.  And the value many people seem to assign to the
> issue (albeit which I'm not presupposing is merited) suggests that
> making any useful improvements to LLVM in this case should be doable.
> (Easy to say without volunteering to do it myself, I know...)

Unwinding is a stateful effect, and any code that would be otherwise
pure is no longer pure if it has the potential to unwind. It's not
simply a matter of unwinding or not unwinding, the compiler needs to
ensure that the source of the unwinding is the same.

An abort (`llvm.trap`) or undefined behaviour is similar in that it adds
an effect and prevents the compiler from doing as much with the code.
However, the unwinding invariants are harder to maintain and LLVM
doesn't even take on this problem.

> Even if this turns out to be a bad idea in the end, I'm not sure this
> thread has enough of a real, measured idea of the costs involved yet,
> and again, people seem to think it's important enough that I don't
> think it's worth giving up without that.  Yes, even though 1.0 is
> soon.  Just my two cents.

I provided an example demonstrating the cost with `clang`.




signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 22/06/14 06:43 PM, Clark Gaebel wrote:
> 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::())
> 
> Where adding a ~ to the end of an operator makes it check for overflow.
> This would certainly look nicer than stuff like:
> 
>> malloc(number_of_elements.checked_add(12).checked_mul(size_of::()))
> 
> lying around in low level data structures code.
> 
> It also keeps the default fast, which is very important.
> 
>   - Clark

Along with an opt-in lint to warn about usage of the unchecked
operators, I think that's the way to go. Since it would be backwards
compatible, it doesn't need to be done before 1.0.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 22/06/14 11: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
>> SIGFPE / SIGSEGV on *nix) into well defined unwinding in LLVM.
> 
> GCJ did it. Presumably JavaScriptCore does it too. How?
> 
> Patrick

AFAIK, LLVM doesn't support unwinding from an asynchronous signal
handler with defined behaviour.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 22/06/14 07:24 PM, Andrew Poelstra wrote:
> 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 enforcing safety via type-checked lifetimes.
>>
>> You can write an efficient low-level loop in Haskell or Swift, but you
>> can't build high level safe abstractions without paying a runtime cost.
>>
>> If someone isn't interested in this approach, then I have a hard time
>> understanding why they would be using Rust.
>>
> 
> This is a bit of an aside, but the reason to use Rust if you don't care
> about performance is that it not only tracks lifetimes, but tracks
> ownership as well. As a side-effect, tracking lifetimes then becomes
> much easier, as does eliminating manual memory management.

I don't understand what you mean here. Rust's lifetimes don't represent
object lifetimes, they represent minimum reference lifetimes. Move
semantics are a way of passing on the responsibility of calling the
destructor.

There is no tracking of ownership in the type system, as shown by the
existence of types like `Rc`. With `Rc`, the programmer is
responsible for ensuring that there are no ownership cycles because the
compiler is unable to track this, it can only deal with destructors at a
scope-based level.

A managed language will not destroy an object until all references to
the object are gone. There is no need to track reference lifetimes,
because the references extend the object's lifetime as long as they
exist (they *are* essentially the object).

> This happens to also make sharing data across threads safer as well. (See
> for example basically anything Niko has written on the subject.)

Thread safety is provided via the Send trait, not anything to do with
lifetimes. A garbage collected language could (many do) provide the same
thread safety semantics as Rust. Value types, immutable reference types
and synchronized reference types would be sendable.

Rust only gains efficiency from the type system, not any form of thread
safety that's not available to a garbage collected language. It's able
to send `Box` data structures without performing a deep copy.

In the future, it will be possible to share disjoint `&mut T` between
parallel jobs (but not normal tasks) but this is also just an efficiency
improvement over other safe alternatives.

> This, along with immutable-by-default and an aversion to magic implicit
> behaviour (e.g. the Rc::clone() argument in the next thread), result in
> a language which is extremely easy to analyze. It makes things harder to
> write, but much easier to read.

It has immutable variables by default, but the contents can still be
mutable via internal (Cell, RefCell, RWLock, Mutex, atomics) or external
(&mut, slice::MutItems) mutability at a type level.

Removing the variable-level immutability was proposed, and it could
still happen at this point:

http://smallcultfollowing.com/babysteps/blog/2014/05/13/focusing-on-ownership/

It's true that there are no *user-defined* copy/move constructors, but
`Gc` *does* have magical implicit glue code running on assigning and
parameter passing. The language just doesn't allow you to do the same
thing in your own code.

> Perhaps you can point out another language that does all this. You
> definitely can't point out another language that does all this, -and-
> has the massive community around it that Rust does.
> 
> 
> So there is a strong reason to use Rust even if you don't care too much
> about performance.
> 
> 



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 22/06/14 08:25 PM, Jerry Morrison wrote:
> 
> The post also links to Wikipedia on 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 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 unwinding in LLVM.

> (BTW is there a use for /signed/ wraparound?)

Yes, but it's not as common so C leaves it as undefined for portability
to architectures not using two's complement arithmetic.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 garbage
collection and task-local reference counting. There can never be cycles
here and non-atomic reference counting will be faster along with
maintaining scope-based destruction semantics. I don't see the use case
for duplicating these types with versions wrapped in a specific smart
pointer type.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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, and have
> everybody port their Rust1 code.  (Well, in reality, I would expect that
> most existing code would just continue to work, but some testing will be
> needed).
> Both sound somewhat painful.

It could be done by adding overflow-checked arithmetic operators. A lint
could then be added to warn about uses of the unchecked operators.

The lint would be opt-in, so you could flip it on at the crate level and
then disable it for audited functions.

It would be backwards compatible (post 1.0 feature) and wouldn't change
the meaning of any existing code by introducing dialects via compiler
switches.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 going to be a lot of
> boilerplate.
> 
> Instead, why not take the same road than swift and map +, -, * and / to
> non-wrap-around operators and declare new (more verbose) operators for
> the rare case where performance matters or wrap-around is the right
> semantics ?

That's the wrong default for a performance-centric language.
> 
> 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; so let's make it convenient to
> write safe code and prevent newcomers from shooting themselves in the
> foot by providing safety by default, and for those who profiled their
> applications or are writing hashing algorithms *also* provide the
> necessary escape hatches.

Reducing performance of programs making heavy use of integer arithmetic
by 50%+ is unacceptable.

> This way we can have our cake and eat it too... or am I missing something ?

No one will use the language after seeing that it's slower than Java by
default.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 22/06/14 05:48 PM, Masklinn wrote:
> On 2014-06-22, at 23:31 , Daniel Micay  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, but the default
>>> behavior is no check?  IMO this would be the best of both worlds,
>>> because I would assume that one would really only care about checked
>>> math during testing and dev.
>>
>> You would need to build an entirely separate set of standard libraries
>> with checked overflow.
> 
> From my understanding, everything would be built with checked overflow
> (unless explicitly disabled/bypassed), and the overflow check could be
> disabled at compile-time/.
> 
> I don't think that's a good solution, but that's what Swift's `-Ofast`
> does, it completely removes a number of checks (including overflow
> checking), essentially making the language unsafe but much faster.
> 
> As a side-question, were the performances of ftrapv (in clang) ever
> actually tested? There were some discussion on testing the impact
> in Firefox, but that ended up with GCC's ftrapv being broken and
> not doing anything, and Firefox not working with clang -ftrapv.

It's important to note that `-ftrapv` only adds checks to signed types
and doesn't work with GCC. You need to pass both
`-fsanitize=signed-integer-overflow` and
`-fsanitize=unsigned-integer-overflow` to clang.

> I've not seen any numbers since, just lots of assertions that
> it's far too slow to be an option.

Here's a benchmark of random level generation that made the rounds on
/r/rust and #rust already:

https://github.com/logicchains/levgen-benchmarks

Here is the result with `clang -O3 C.c`:

./a.out 10 &> /dev/null  0.20s user 0.00s system 99% cpu 0.205 total

Here is the result with `clang -O3 -fsanitize=signed-integer-overflow
-fsanitize=unsigned-integer-overflow`:

./a.out 10 &> /dev/null  0.31s user 0.00s system 98% cpu 0.313 total

So in a real world use case consistently partly of integer arithmetic,
it's an absolutely acceptable 50% increase in running time. At that
point, Rust would be a much slower language than Java by default and no
one would use it.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 its security implications, and
> other forms of program correctness are not?

Rust's goal has been to bring modern language features to the systems
programming world (sum types, traits, pattern matching) and make the
necessary sacrifices to achieve memory safety. Rust isn't intended to be
all things to all people. Most of the complexity budget has been spent
providing memory safety without making performance sacrifices.

Bounds checks are already one of the most serious barriers to adoption
as a replacement for C and C++. A lot of effort will need to go into
exposing safe APIs (like iterators) for sidestepping this overhead. At
the moment, the unchecked indexing methods are required in many cases to
avoid a large performance loss relative to C and the code ends up being
far uglier than it would have been in C.

Rust could provide checked arithmetic, but it can't make use of it in
the standard libraries. It wouldn't improve the safety of the language
because any performance critical low-level code using `unsafe` is going
to want to avoid paying the cost of bounds checks.

It's not simply a language issue, because libraries would need to expose
methods with and without the overflow checks whenever they're doing
arithmetic with the parameters.

> I am wary of circling around on this topic again, but I feel that the
> biggest mistake in this discussion js that checked overflow in a
> language requires a potential trap on every single integer operation.
> Languages like Ada (and Swift, to a lesser extent), allow for slightly
> imprecise exceptions in the case of integer overflow.
> 
> A fairly simple rule is that a check for overflow only needs to occur
> before the incorrect result may have externally visible side effects.
> Ada’s rule even lets you go a step further and remove overflow checks
> from loops  in some cases (without violating control dependence of the
> eventual overflowing operation).
> 
> One model like this that has been proposed for C/C++ is the “As
> Infinitely Ranged” model (see
> http://www.cert.org/secure-coding/tools/air-integer-model.cfm), where
> operations either give the result that would be correct if integers had
> infinite precision, or cause a trap. This allows for more optimizations
> to be performed, and although it is questionable to me whether they
> preserved control dependence of overflow behavior in all cases, they
> report a 5.5% slowdown on SPEC2006 with GCC 4.5 (compared to a 13%
> slowdown with more plentiful checks) using a very naive implementation.
> A lot of those checks in SPEC2006 could probably just be eliminated if
> the language itself distinguished between overflow-trapping and
> overflow-permissive operations. If a compiler optimizer understood the
> semantics of potentially trapping integer operations better (or at all),
> it could reduce the overhead of the checks.
> 
> I know that some people don’t want to require new compiler techniques
> (or are afraid of relying on something outside of the scope of what LLVM
> can handle today), but it would be unfortunate for Rust to make the
> wrong decision here based on such incidental details rather than what is
> actually possible.

Graydon was always adamant that the language should use proven
techniques and should avoid depending on a non-existent compiler
optimization or immature research.

For a language calling itself pragmatic, it has certainly spent a great
deal of time getting to 1.0 and already ventures a fair bit outside of
proven techniques (lifetimes).

The focus should be on releasing an elegant language with memory safety
and competitive performance with C++. Adding new features to the
language at this point rather than refining the existing ones would be a
huge mistake. A feature like checked arithmetic or tail call elimination
can and should go through experiments behind feature gates, but it
doesn't belong in a 1.0 release.

If you don't agree with the fundamental language design at this point,
that's too bad because it's 6 months away from 1.0 and you're too late.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 both worlds,
> because I would assume that one would really only care about checked
> math during testing and dev.

You would need to build an entirely separate set of standard libraries
with checked overflow. Adding new dialects of the language via compiler
switches is never the right answer. It seems that every time an issue
like this comes up, people propose making a compiler switch as the option.

If we had compiler switches for abort vs. unwinding, no tracing gc
support vs. tracing gc support, no integer overflow checks vs. integer
overflow checks and more, we would have a truly ridiculous number of
language dialects. I think even 2 dialects is too much...



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 extreme
> end of the programming spectrum where edge cases are the norm, not the
> exception, and where 80/20 does not apply. If you don't require absolute
> speed, why are you using Rust?

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 enforcing safety via type-checked lifetimes.

You can write an efficient low-level loop in Haskell or Swift, but you
can't build high level safe abstractions without paying a runtime cost.

If someone isn't interested in this approach, then I have a hard time
understanding why they would be using Rust.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 not really sure what you mean by "low-level control". I'm also not
sure why you would want such a thing if not for performance.

> Because of a small memory footprint?

The memory footprint depends more on the application code than anything
else. A language using garbage collection might use 3x as much memory or
more, but using implicit atomic reference counting like Swift avoids the
need for the programmer to manage ownership / lifetimes without
introducing significant memory usage overhead. Rust is a bad choice if
performance isn't critical, because those features exist for the sake of
performance.

> Because of having a good async story without giving up a lot of speed?

Rust has exactly zero support for async / non-blocking I/O. The only
form of I/O in Rust will block a task, meaning each waiting I/O
operation is consuming an entire stack. Avoiding the overhead of a stack
per I/O concurrent operation is the rationale behind async /
non-blocking I/O.

> There are plenty of other features to Rust then "absolute speed". Just
> because that's /your/ usecase for it doesn't mean you should force it on
> others.

The set of design compromises made by the language is ill-suited to a
use case where performance isn't critical. There's a high cost to having
the programmer manage object lifetimes, and a language without the same
focus on performance can avoid this entirely.

Swift shares many of the design characteristics of Rust (like traits),
with C#-style value types and reference types. Rather than references as
values where the programmer has to deal with lifetimes, reference types
have their lifetime managed by a garbage collector (C#) or reference
counting (Swift).

I have a hard time seeing why someone would choose Rust over a language
like that if they didn't care about a focus on performance *across the
application* rather than just for inner loops. Rust's strength is the
ability to build high-level abstractions without making performance
compromises. You can still have low-level control in Swift, but you
can't have both low-level control and high-level / safe abstractions.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

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 very common pure
operations with impure ones in most code will destroy performance. Rust
relies heavily on compiler optimizations to even come close to C level
performance. Anyway, no one has offered an explanation of how they're
planning on integrating this into LLVM and how they propose turning a
trapping operation into unwinding across various platforms.

> My primary motivation is that, outside of a couple of specialized cases
> like hashing and checksums, wraparound semantics on overflow is
> **wrong**. It may be well-defined behavior, and it may be fast, but it's
> **wrong**. What's the value of a well-defined, performant semantics
> which does the wrong thing?

Few functions check all of the necessary preconditions. For example, a
binary search implementation doesn't check to see if the array is
sorted.  It's not incorrect to require a precondition from the caller
and overflow is only one of countless cases of this.

Choosing to enforce invariants in the type system or checking them at
runtime is always a compromise, and Rust eschews runtime checks not
strictly required for memory safety.

In some cases, the type system has been leveraged to enforce invariants
at compile-time (Ord vs. PartialOrd) but even though that's quite easy
to sidestep, it's not without drawbacks.

> I also agree that performance is non-negotiable in this case, however.
> The only good thing about always wrong is that it's not that hard to do
> better.
> 
> Given the circumstances, I think the least bad outcome we could achieve,
> and which we *should* aim to achieve, would be this:
> 
>  * Where performance is known to not be a requirement, Rust code in the
> wild uses either overflow-checked arithmetic or unbounded integer types,
> with the choice between them depending on ergonomic and semantic
> considerations.
> 
>  * When the performance requirement can't be ruled out, Rust code in the
> wild uses arithmetic for which overflow checking can be turned on or off
> with a compiler flag. For testing and debugging, it is turned on. For
> production and benchmarks, it is turned off.

The Rust developers have been consistently opposed to introducing
dialects of the language via compiler switches. I brought up the issue
of macros and syntax extensions but you've chosen to ignore that.

>  * For code where wraparound semantics is desired, the appropriate
> facilities are also available.
> 
> Given the discussion so far, the design I'd be leaning toward to
> accomplish the above might be something like this:
> 
>  * Two sets of fixed-sized integer types are available in the `prelude`.
> 
>  * `u8`..`u64`, `i8`..`i64`, `int`, and `uint` have unspecified results
> on overflow (**not** undefined behavior). A compiler flag turns overflow
> checks on or off. Essentially, the checks are `debug_assert`s, though
> whether they should be controlled by the same flag is open to debate.
>
>  * `uc8`..`uc64`, `ic8`..`ic64`, `intc`, and `uintc` are *always*
> checked for overflow, regardless of flags. (Names are of course open to
> bikeshedding.)
> 
>  * Given that these are not really different semantically, automatic
> coercions between corresponding types can be considered. (Even then, for
> `a + b` where `a: int` and `b: intc`, explicit disambiguation would
> presumably still be required.)
> 
>  * Unbounded integer types using owned memory allocation are available
> in the `prelude`. I might prefer to call them `Integer` and `Natural`
> instead of `BigInt` and `BigUint`.
> 
>  * Types and/or operations which wrap around on overflow are available
> in the standard library. Given how specialized the use cases for these
> seem to be, perhaps they could even go directly in the `hash` module.
> It's not clear to me yet whether a separate set of types (`uw8`..`uw64`,
> `iw8`..`iw64`) or just a separate set of operations on the `prelude`
> types (e.g. `trait WrappingAdd`) would be preferable.

A `Vec` and `Vec` would be entirely distinct types. That
alone is going to cause performance issues and will make the language
more painful to use. It's already pushing the boundaries of what people
will be willing to accept with features like strictly checked move
semantics and reference lifetimes.

>  * Unbounded integer types which use garbage collected allocation are
> available in the `gc` module.

It doesn't sense to have 3 separate implementations of big integers for
reference counting, atomic reference counting and task-local tracing
garbage collection.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 08:16 PM, Tony Arcieri wrote:
> On Sat, Jun 21, 2014 at 4:55 PM, Benjamin Striegel
> mailto:ben.strie...@gmail.com>> wrote:
> 
> In addition, bringing up hypothetical CPU architectures with support
> for checked arithmetic is not relevant. Rust is a language designed
> for 2014, not for 2024.
> 
> 
> So why not do the safe thing by default (which future CPUs may make
> fast), and provide a secondary mechanism to get the "unsafe" fast path?

CPU support for trapping on overflow will not make it fast. Either way,
it makes every integer arithmetic operation impure and will wipe out
many optimizations.

The claim that a CPU can make this faster is conjecture until someone
explains how we can actually leverage it. Turning trapping on overflow
into unwinding on overflow is not a trivial issue and would involve
changes to LLVM's design along with potentially non-portable platform
support for handling the trapping via a signal handler and then throwing
an asynchronous exception.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 07:55 PM, Benjamin Striegel wrote:
>> No one will use Rust if it's slow. If it uses checked arithmetic, it
>> will be slow. There's nothing subjective about that.
> 
> This is the only argument that matters.
> 
> If we are slower than C++, Rust will not replace C++ and will have
> failed at its goal of making the world a safer place. The world already
> has a glut of safe and slow languages; if inefficiency were acceptable,
> then C++ would have been replaced long ago.
> 
> In addition, bringing up hypothetical CPU architectures with support for
> checked arithmetic is not relevant. Rust is a language designed for
> 2014, not for 2024.
> 
> And if in 2024 we are all suddenly gifted with CPUs where checked
> arithmetic is literally free and if this somehow causes Rust to be
> "obsolete" (which seems unlikely in any case), then so be it. Rust is
> not the last systems programming language that will ever be written.

Not only does the hardware have to provide it, but each OS also has to
expose it in a way that Rust could use to throw an exception, unless the
proposal is to simply abort on overflow. LLVM would also have to gain
support for unwinding from arithmetic operations, as it can't currently
do that. Even with hardware support for the operation itself, giving
every integer operation a side effect would still cripple performance by
wiping out optimizations.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 07:27 PM, Jerry Morrison wrote:
> 
> On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay  <mailto:danielmi...@gmail.com>> wrote:
> 
> On 21/06/14 06:54 PM, Jerry Morrison wrote:
> > I agree with Vadim that the world will inevitably become
> > security-conscious -- also safety-conscious. We will live to see it
> > unless such a bug causes nuclear war or power grid meltdown.
> >
> > When the sea change happens, Rust will either be (A)/ the attractive
> > choice for systems programming/ or (B) /obsolete/. Rust already
> has the
> > leading position in memory safety for systems programming, so it's
> lined
> > up to go.
> 
> No one will use Rust if it's slow. If it uses checked arithmetic, it
> will be slow. There's nothing subjective about that.
> 
> 
> Surely there's a way to make the language and libraries ready for
> overflow safety while able to perform without it in the short term.

I'm not sure what you mean by this. If one day ARM gets instructions for
trapping on overflow, that's all well and good, but Rust can't use it to
implement fail-on-overflow. If the proposal was based around aborting on
overflow rather than failing, it would be able to use those instructions.

> > The world desperately needs a C++ replacement for real-time,
> > safety-critical software before that ever-more-complicated language
> > causes big disasters. Rust is the only candidate around for that. (Or
> > maybe D, if its real-time threads can avoid GC pauses.) CACM's recent
> > /Mars Code/ article
> > <http://cacm.acm.org/magazines/2014/2/171689-mars-code/fulltext> shows
> > the extremes that JPL has to do to program reliable space probes.
> > Smaller companies writing automobile engine control systems
> >
> 
> <http://www.edn.com/design/automotive/4423428/Toyota-s-killer-firmware--Bad-design-and-its-consequences>
> > and such will soon be looking for a more cost effective approach.
> 
> Trapping on overflow doesn't turn the overflow into a non-bug. It
> prevents it from being exploited as a security vulnerability, but it
> would bring down a safety critical system.
> 
> 
> A safety critical system needs to catch and recover from thread
> failures, e.g. by restarting it, or failing over, or gracefully shutting
> down. The first requirement is to keep the problem from causing
> collateral damage and opening exploitable holes. Systems like phone
> switches written in Erlang are good at the recovery part.
> 
> (And by "smaller companies" I meant "smaller, less funded teams.")

Rust's task failure isn't very isolated or robust. A failure in a
destructor called during failure will abort the process. A failure in a
destructor when not already failing will not call the inner destructors
as it would be memory unsafe.

A failure also has to poison RWLock / Mutex so that all other threads
with handles to the same shared data will fail too. I don't think these
issues are going to be fixed, unwinding in a language with destructors
is just inherently broken.

I think process separation is a far better option for robust systems.

> > Companies like Intel see so much existing C/C++ software getting by
> > without overflow safety and conclude it doesn't matter. Let's not let
> > their rear-view mirror thinking keep us stuck. Eventually
> customers will
> > demand better security whether there's a speed penalty or not.
> >
> > CPU designers could say they've given us so much instruction speed
> that
> > we can afford to spend some of it on overflow checking. Fair
> point. When
> > the software folks have demonstrated the broad need, Intel can
> speed it
> > up, whether by optimizing certain instruction sequences or adding new
> > instructions.
> 
> Overflow checking means a branch on every integer arithmetic operation.
> 
> It means every arithmetic operation is impure (unwinding) so LLVM won't
> be able to hoist stuff out of loops unless it proves that there's no
> overflow, which is rare. For example, this prevents it from hoisting a
> bounds check out of a loop by introducing a second kind of impure
> failure condition.
> 
> It also prevents auto-vectorization, which is increasingly important. A
> language without good auto-vectorization is not going to be an
> interesting systems language down the road.
> 
> 
> How about propagating the overflow info downstream like a NaN by a
> limited distance, rather than throwing an immediate exception?

The hardware doesn't support this. Any kind of checked overflow means no
auto-vectorization. You only get wrapping arithmetic and in some cases
saturing arithmetic.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 06:26 PM, comex wrote:
> On Sat, Jun 21, 2014 at 6:02 PM, Daniel Micay  wrote:
>> It's not possible to add new instructions to x86_64 that are not large
>> and hard to decode. It's too late, nothing short of breaking backwards
>> compatibility by introducing a new architecture will provide trapping on
>> overflow without a performance hit. To repeat what I said elsewhere,
>> Rust's baseline would still be obsolete if it failed on overflow because
>> there's no indication that we can sanely / portably implement failure on
>> overflow via trapping. It's certainly not possible in LLVM right now.
> 
> Er... since when?  Many single-byte opcodes in x86-64 corresponding to
> deprecated x86 instructions are currently undefined.

http://ref.x86asm.net/coder64.html

I don't see enough gaps here for the necessary instructions.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 06:54 PM, Jerry Morrison wrote:
> I agree with Vadim that the world will inevitably become
> security-conscious -- also safety-conscious. We will live to see it
> unless such a bug causes nuclear war or power grid meltdown.
> 
> When the sea change happens, Rust will either be (A)/ the attractive
> choice for systems programming/ or (B) /obsolete/. Rust already has the
> leading position in memory safety for systems programming, so it's lined
> up to go.

No one will use Rust if it's slow. If it uses checked arithmetic, it
will be slow. There's nothing subjective about that.

> The world desperately needs a C++ replacement for real-time,
> safety-critical software before that ever-more-complicated language
> causes big disasters. Rust is the only candidate around for that. (Or
> maybe D, if its real-time threads can avoid GC pauses.) CACM's recent
> /Mars Code/ article
>  shows
> the extremes that JPL has to do to program reliable space probes.
> Smaller companies writing automobile engine control systems
> 
> and such will soon be looking for a more cost effective approach.

Trapping on overflow doesn't turn the overflow into a non-bug. It
prevents it from being exploited as a security vulnerability, but it
would bring down a safety critical system.

> Companies like Intel see so much existing C/C++ software getting by
> without overflow safety and conclude it doesn't matter. Let's not let
> their rear-view mirror thinking keep us stuck. Eventually customers will
> demand better security whether there's a speed penalty or not.
> 
> CPU designers could say they've given us so much instruction speed that
> we can afford to spend some of it on overflow checking. Fair point. When
> the software folks have demonstrated the broad need, Intel can speed it
> up, whether by optimizing certain instruction sequences or adding new
> instructions.

Overflow checking means a branch on every integer arithmetic operation.

It means every arithmetic operation is impure (unwinding) so LLVM won't
be able to hoist stuff out of loops unless it proves that there's no
overflow, which is rare. For example, this prevents it from hoisting a
bounds check out of a loop by introducing a second kind of impure
failure condition.

It also prevents auto-vectorization, which is increasingly important. A
language without good auto-vectorization is not going to be an
interesting systems language down the road.

> The Mill CPU architecture handles overflow nicely and promises much
> higher performance, like extending DSP abilities into ordinary software
> loops like strncpy(). Whether this one takes off or not is hard to say.
> That little company could use a big partner.

It has to exist before it can succeed or fail.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 05:47 PM, Tony Arcieri wrote:
> On Sat, Jun 21, 2014 at 2:42 PM, Daniel Micay  <mailto:danielmi...@gmail.com>> wrote:
> 
> ARM and x86_64 aren't going anywhere and it's too late for trap on
> overflow to be part of the baseline instruction set. It's far from a
> sure thing that it would even be added.
> 
> 
> Having watched the debacle that was Azul trying to get features added to
> Intel CPUs, like hardware transactional memory or realtime zeroing into
> L1 cache, I strongly agree. We can't assume anything about the hardware
> manufacturers will do, they just don't care about this stuff, and their
> roadmaps for adding anything like this are terrible at best.
> 
> But here's a hypothetical situation: it's 202X and after much ado Intel,
> ARM, AMD, and others have just rolled out some new CPU instructions and
> fancy new ALU with fast overflow detection in hardware. Overflow
> detection is fast now!
> 
> If that ever happened, what Rust provides as a baseline today would be
> obsolete and broken. In the distant future. But still...

It's not possible to add new instructions to x86_64 that are not large
and hard to decode. It's too late, nothing short of breaking backwards
compatibility by introducing a new architecture will provide trapping on
overflow without a performance hit. To repeat what I said elsewhere,
Rust's baseline would still be obsolete if it failed on overflow because
there's no indication that we can sanely / portably implement failure on
overflow via trapping. It's certainly not possible in LLVM right now.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 21/06/14 05:21 PM, Vadim Chugunov 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 this happens.  So I would propose the following practical solution
> (I think Gabor is also leaning in favor of something like this):

ARM and x86_64 aren't going anywhere and it's too late for trap on
overflow to be part of the baseline instruction set. It's far from a
sure thing that it would even be added. The small x86_64 instructions
are all used up so it's impossible to add trap on overflow without more
expensive instruction decoding and bloated code size.

Anyway, trapping would *not* map to how Rust currently deals with logic
errors. It would need to give up on unwinding for logic errors in order
to leverage these kinds of instructions. The alternative is depending on
asynchronous unwinding support and OS-specific handling for the trapping
instructions (SIGFPE like division by zero?).

Processors already implement a trap on division by zero but Rust is
currently not able to take advantage of it... until we're doing it for
division, there's no indication that we'll be able to do it for other
operations.

> 1. Declare that regular int types (i8, u8, i32, u32, ...) are
> non-wrapping. 
> Check them for overflow in debug builds, maybe even in optimized builds
> on platforms where the overhead is not too egregious.  There should
> probably be a per-module performance escape hatch that disables overflow
> checks in optimized builds on all platforms.  On zero-cost overflow
> checking platforms, the checks would of course always be on.
> Also, since we are saving LLVM IR in rlibs for LTO, it may even be
> possible to make this a global (i.e. not just for the current crate)
> compile-time decision.

If they're not defined as wrapping on overflow, how *are* they defined?

It does have to be defined as something, even if that means an arbitrary
result left up to the implementation. The result must be consistent
between reads to maintain memory safety.

> 2. Introduce new wrapping counterparts of the above for cases when
> wrapping is actually desired.
> 
> If we don't do this now, it will be much more painful later, when large
> body of Rust code will have been written that does not make the
> distinction between wrapping and non-wrapping ints.
> 
> Vadim



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] On Copy = POD

[Daniel Micay]

On 21/06/14 02:06 AM, Nick Cameron wrote:
> bstrie: you're right it is a trade off, but I don't agree that its not
> worth it. We're talking about non-atomic incrementing of an integer -
> that is pretty much the cheapest thing you can do on a processor (not
> free of course, since caching, etc., but still very cheap). I've
> programmed a lot in C++ with ref counted pointers and never had a
> problem remembering that there is a cost, and it makes using them
> pleasant. I found all the clone()s in Rust unpleasant, it really put me
> off using ref counting. The transition from using references to using Rc
> was particularly awful. Given that this is something C++ programmers
> coming to Rust will be used to using, I believe ergonomics is especially
> important.
> 
> In this case I don't think we need to aim to be more 'bare metal' than
> C++. Transparent, ref counted pointers in C++ are popular and seem to
> work pretty well, although obviously not perfectly.
> 
> zwarich: I haven't thought this through to a great extent, and I don't
> think here is the right place to plan the API. But, you ought to still
> have control over whether an Rc pointer is copied or referenced. If you
> have an Rc object and pass it to a function which takes an Rc, it
> is copied, if it takes a &Rc or a &T then it references (in the
> latter case with an autoderef-ref). If the function is parametric over U
> and takes a &U, then we instantiate U with either Rc or T (in either
> case it would be passed by ref without an increment, deciding which is
> not changed by having a copy constructor). If the function takes a U
> literal, then U must be instantiated with Rc. So, you still get to
> control whether you reference with an increment or not.
> 
> I think if Rc is copy, then it is always copied. I would not expect it
> to ever move. I don't think that is untenable, performance wise, after
> all it is what everyone is currently doing in C++. I agree the second
> option seems unpredictable and thus less pleasant.

It's a severe performance issue in C++11 with `std::shared_ptr` because
it uses atomic reference counting.

Even for `Rc`, these writes cause significant issues for alias
analysis and end up causing many missed optimizations.

Rust needs a way to elide them, and with the `move` keyword gone that
means last use analysis or maintaining the current situation where Rust
always performs the same operation as C for passing, returning and
assignment (a shallow copy).

It will be much harder to write failure-safe code if basic operations
like assignment can fail.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] optimizing away const/pure function calls?

[Daniel Micay]

On 20/06/14 02:02 PM, Josh Haberman wrote:
> Does Rust have any way of optimizing away repeated calls to the same
> function where possible? Like GCC's "pure" function attribute?
> 
> To get a little more crazy, say you're working with a Map. Sometimes
> it's convenient to write code like this:
> 
>   if (map.contains_key(foo)) {
> let val = map.get(foo);
> // ...
>   }
> 
> This code, naively compiled, would perform two lookups. But only one is
> logically required, and caching the lookup would only require a single
> pointer.
> 
> Is there any reasonable scenario under which the compiler could decide
> to allocate stack space to cache that lookup, so that the code above
> would be optimized to only perform one lookup?
> 
> Josh

Rust has no way to mark effects. LLVM is able to infer the readonly,
readnone and nounwind attributes in some cases, but not most.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Why are generic integers not usable as floats?

[Daniel Micay]

On 20/06/14 07:36 AM, Nathan Typanski wrote:
> On 06/19, Benjamin Striegel wrote:
>> I'm actually very pleased that floating point literals are entirely
>> separate from integer literals, but I can't quite explain why. A matter of
>> taste, I suppose. Perhaps it stems from symmetry with the fact that I
>> wouldn't want `let x: int = 1.0;` to be valid.
> 
> I agree that `let x: int = 1.0` should not be valid. But that is type
> *demotion*, and with `let x: f32 = 1` we are doing type *promotion*.
> Demotion is not exactly popular among languages, but promotion has
> some arguments going for it.
> 
> The literal is an integer type (at least by how my brain parses it),
> and it is being implicitly promoted to a float.
> 
> Now, in the following instance, I have to explicitly convert `y` to a
> `f32` type before it compiles. There's no implicit promotion when
> performing addition.
> 
> let x: f32 = 1.0;
> let y: int = 1;
> print!("{}", x + y as f32);
> 
> So the question is: do we want to make a special case where we do
> implicit type promotion at assignment, and nowhere else?
> 
> I say no. Either you are picky about your numeric types, or you do
> type promotion everywhere, but not both. Personally I would sooner not
> think about edge cases here, and just say that all numeric types
> should be explicit.
> 
>Nathan

It wouldn't be a type conversion at all. The literal `1` does not have
the type `int`, it's a generic integer literal with an inferred type.

In Haskell, `1` is a generic *number* literal and can be inferred as any
kind of integer, floating point, fixed point or rational type.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 19/06/14 03:05 AM, Jerry Morrison wrote:
>
> BigUint is weird: It can underflow but not overflow. When you use its
> value in a more bounded way you'll need to bounds-check it then, whether
> it can go negative or not. Wouldn't it be easier to discard it than
> squeeze it into the wraparound or checked models?

I don't think we should have a big unsigned integer. It's not something
I've seen other big integer libraries do.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 18/06/14 03:40 PM, comex wrote:
> On Wed, Jun 18, 2014 at 1:08 PM, Gábor Lehel  wrote:
>> To partially address this, once we have tracing GC, and if we manage to make
>> `Gc: Copy`, we should add unbounded `Integer` (as in Haskell) and
>> `Natural` types which internally use `Gc`, and so are also `Copy`. (In
>> exchange, they wouldn't be `Send`, but that's far less pervasive.)
> 
> Wait, what?  Since when is sharing data between threads an uncommon use case?

Data remaining local to the thread it was allocated in is the common
case. That doesn't mean that sending dynamic allocations to other tasks
or sharing dynamic allocations is bad. `Rc` is inherently local to a
thread, so it might as well be using an allocator leveraging that.

> (Personally I think this more points to the unwieldiness of typing
> .clone() for cheap and potentially frequent clones like Rc...)

Either way, it doesn't make sense to make a special case for `Gc`.

If `copy_nonoverlapping_memory` isn't enough to move it somewhere, then
it's not `Copy`. A special-case shouldn't be arbitrarily created for it
without providing the same thing for user-defined types. That's exactly
the kind of poor design that Rust has been fleeing from.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Integer overflow, round -2147483648

[Daniel Micay]

On 18/06/14 01:08 PM, Gábor Lehel wrote:
> # Exposition
> 
> We've debated the subject of integer overflow quite a bit, without much
> apparent progress. Essentially, we've been running in circles around two
> core facts: wrapping is bad, but checking is slow. The current consensus
> seems to be to, albeit grudgingly, stick with the status quo.
> 
> I think we've established that a perfect, one-size-fits-all solution is
> not possible. But I don't think this means that we're out of options, or
> have no room for improvement. I think there are several imperfect,
> partial solutions we could pursue, to address the various use cases in a
> divide-and-conquer fashion.
> 
> This is not a formal RFC, more of a grab bag of thoughts and ideas.
> 
> The central consideration has to be the observation that, while wrapping
> around on overflow is well-supported by hardware, for the large majority
> of programs, it's the wrong behavior.
> 
> Basically, programs are just hoping that overflow won't happen. And if
> it ever does happen, it's going to result in unexpected behavior and
> bugs. (Including the possibility of security bugs: not all security bugs
> are 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 affairs. If we're clearing the bar, that's
> only because it's been buried underground.
> 
> We can divide programs into three categories. (I'm using "program" in
> the general sense of "piece of code which does a thing".)
> 
>  1) Programs where wrapping around on overflow is the desired semantics.
> 
>  2) Programs where wrapping around on overflow is not the desired
> semantics, but performance is not critical.

If performance wasn't critical, the program wouldn't be written in Rust.
The language isn't aimed at use cases where performance isn't a bug
deal, as it makes many sacrifices to provide the level of control that's
available.

>  3) Programs where wrapping around on overflow is not the desired
> semantics and performance is critical.
> 
> Programs in (1) are well-served by the language and libraries as they
> are, and there's not much to do except to avoid regressing.
> 
> Programs in (2) and (3) are not as well-served.
>
>
> # Checked math
> 
> For (2), the standard library offers checked math in the `CheckedAdd`,
> `CheckedMul` etc. traits, as well as integer types of unbounded size:
> `BigInt` and `BigUint`. This is good, but it's not enough. The acid test
> has to be whether for non-performance-critical code, people are actually
> *using* checked math. If they're not, then we've failed.
>
> `CheckedAdd` and co. are important to have for flexibility, but they're
> far too unwieldy for general use. People aren't going to write
> `.checked_add(2).unwrap()` when they can write `+ 2`. A more adequate
> design might be something like this:
> 
>  * Have traits for all the arithmetic operations for both checking on
> overflow and for wrapping around on overflow, e.g. `CheckedAdd` (as
> now), `WrappingAdd`, `CheckedSub`, `WrappingSub`, and so on.
> 
>  * Offer convenience methods for the Checked traits which perform
> `unwrap()` automatically.
> 
>  * Have separate sets of integer types which check for overflow and
> which wrap around on overflow. Whatever they're called: `CheckedU8`,
> `checked::u8`, `uc8`, ...
> 
>  * Both sets of types implement all of the Checked* and Wrapping*
> traits. You can use explicit calls to get either behavior with either types.
> 
>  * The checked types use the Checked traits to implement the operator
> overloads (`Add`, Mul`, etc.), while the wrapping types use the Wrapping
> traits to implement them. In other words, the difference between the
> types is (probably only) in the behavior of the operators.
> 
>  * `BigInt` also implements all of the Wrapping and Checked traits:
> because overflow never happens, it can claim to do anything if it "does
> happen". `BigUint` implements all of them except for the Wrapping traits
> which may underflow, such as `WrappingSub`, because it has nowhere to
> wrap around to.
> 
> Another option would be to have just one set of types but two sets of
> operators, like Swift does. I think that would work as well, or even
> better, but we've been avoiding having any operators which aren't
> familiar from C.
> 
> 
> #  Unbounded integers
> 
> While checked math helps catch instances of overflow and prevent
> misbehaviors and bugs, many programs would prefer integer types which do
> the right thing and don't overflow in the first place. For this, again,
> we currently have `BigInt` and `BigUint`. There's one problem with
> these: because they may allocate, they no longer `Copy`, which means
> that they can't be just drop-in replacements for the fixed-size types.
>
>
> To partially address this, once we have tracing GC, and if we manage to
> make `Gc: Copy`, we sh

Re: [rust-dev] &self/&mut self in traits considered harmful(?)

[Daniel Micay]

On 11/06/14 01:54 PM, Tommi wrote:
> If the `Mul` trait and similar were changed to take `self` by value, perhaps 
> the following kind of language design would make more sense:
> 
> If a variable of a type that has a destructor is passed to a function by 
> value (moved), and the variable is used after the function call, the variable 
> would be implicitly cloned before passing it to the function.

Cloning big integers, rationals based on big integers or arbitrary
precision floating point values for every single operation has a high
cost. One of Rust's strength's is that it doesn't have implicit cloning
as C++ does due to copy constructors.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Designing long-running subtasks

[Daniel Micay]

On 05/06/14 02:27 AM, Paul Nathan wrote:
> 
> This won't work in a CSP system. So 

Rust isn't a pure CSP system. It has both immutable and mutable shared
memory alongside various forms of channels. The best tool for the job
will vary based on the specific use case. Channels will often be the
right choice, but there's no need to prefer them when using shared state
maps better to the problem. Either way, Rust prevents data races.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] A better type system

[Daniel Micay]

On 03/06/14 05:58 AM, Sebastian Gesemann wrote:
> On Mon, Jun 2, 2014 at 10:09 PM, Matthew McPherrin wrote:
>> On Mon, Jun 2, 2014 at 8:25 AM, Patrick Walton wrote:
>>> On 6/2/14 12:44 AM, Tommi wrote:

 In my original post I stated that it feels like there's something wrong
 with the language when it doesn't allow multiple mutable references to
 the same data, but I didn't really explain why it feels like that. So, I
 just want to add this simple example to help explain my position. It is
 just plain obvious to everybody that the following code snippet is
 memory-safe, but the compiler refuses to compile it due to "cannot
 borrow `stuff[..]` as mutable more than once at a time":

 let mut stuff = [1, 2, 3];
 let r1 = stuff.mut_slice_to(2);
 let r2 = stuff.mut_slice_from(1);
>>>
>>> I'd like to have a function that splits up a vector in that way. That
>>> should be doable in the standard library using some unsafe code under the
>>> hood.
>>
>> Isn't this MutableVector's mut_split_at that we already have?
> 
> I thought about mentioning mut_split_at just to make people aware of
> it. But the resulting slices are not overlapping which is apparently
> what Tommi was interested. My understanding is that even if one uses
> an unsafe block to get two overlapping mutable slices, the use of
> those might invoke undefined behaviour because it violates some
> aliasing assumptions the compiler tends to exploit during
> optimizations. Correct me if I'm wrong.
> 
> Cheers!
> sg

It causes undefined behaviour because the language is defined that way.

It's defined that way both to allow for data parallelism and type-based
alias analysis. There's potentially room for another form of & reference
with aliasing, mutable data but the existing ones need to stay as they
are today.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Passing arguments bu reference

[Daniel Micay]

On 01/06/14 04:34 AM, Christophe Pedretti wrote:
> Hello all,
> 
> I've read this :
> http://words.steveklabnik.com/pointers-in-rust-a-guide
> 
> I am coming from Java where everything is passed and returned by
> reference (except for primitive data types), no choice.
> 
> I know that with C, you have to use pointers to avoid passing and
> returning by value.
> 
> When i read the mentionned guide, things are not so evident with Rust.
> 
> So, to be precise, imagine i need to write à fonction which takes à
> big Vec (In my case it´s an SQL BLOB) as argument and returns a
> big Vec
> 
> Should i use
> Fn my_func(src : &Vec) -> &Vec
> Fn my_func(src : &Vec) -> ~Vec
> Fn my_func(src : &Vec) ->Vec
> Fn my_func(src : Vec) -> Vec
> Fn my_func(src : ~Vec) -> ~Vec
> Any other combination ?
> 
> Thanks
> 
> PS : i know that i have to use lifetimes and that ~ are now Box, i've
> omitted them to simplify my demand
> PS2 : genrally with a language you can accomplish the same thing with
> different methods, but there are also common "usages", even if Rust is
> young, what is the usage for passing and returning large data values

Vec is always { ptr, len, cap }, it's never larger than 3 words.

Rust *always* passes, assigns and returns exactly as C would. It's a
shallow copy and never runs any magical operations as it can in C++.

You should pass it by-value if the function needs to own a copy of the
vector, and otherwise pass `&[T]` or `&mut [T]`. Using `&Vec` is an
anti-pattern because it offers nothing over `&[T]` and is just less
general. It does make sense to use `&mut Vec` if you want to alter
the length in the function without taking ownership.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Function overloading is necessary

[Daniel Micay]

On 29/05/14 09:46 PM, Daniel Micay wrote:
> On 29/05/14 09:05 PM, Oleg Eterevsky wrote:
>> If a type implements both Iterator and RandomAccessIterator, wouldn't
>> it lead to a conflict?
> 
> No, it won't. There's a default implementation for types implementing
> the Iterator trait, and only a single explicit implementation.
> 
> There are other more flexible ways to do this, but this happens to be
> enough for this use case.

Ah, I missed the point of the example. It's supposed to be implemented
for *all* types implementing both traits, not specific ones. I'll post a
new solution.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Function overloading is necessary

[Daniel Micay]

On 29/05/14 09:05 PM, Oleg Eterevsky wrote:
> If a type implements both Iterator and RandomAccessIterator, wouldn't
> it lead to a conflict?

No, it won't. There's a default implementation for types implementing
the Iterator trait, and only a single explicit implementation.

There are other more flexible ways to do this, but this happens to be
enough for this use case.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] Function overloading is necessary

[Daniel Micay]

On 29/05/14 08:52 PM, Tommi wrote:
> On 2014-05-30, at 3:42, Eric Reed  wrote:
> 
>> Rust *does* have function overloading. That's *exactly* what traits are for.
>> If you want to overload a function, then make it a trait and impl the trait 
>> for all the types you want to overload it with.
> 
> I've been trying to figure out how exactly to do this. How would I write a 
> function that's overloaded based on whether its argument's type implements 
> Iterator or RandomAccessIterator?

Maybe by implementing the function in a trait as a default method and
doing an override for types implementing RandomAccessIterator.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] A few random questions

[Daniel Micay]

On 29/05/14 05:22 PM, Oleg Eterevsky wrote:
>>> What would be Rust alternative, except passing the errors all around
>>> parser? Doesn't it grow parser code by at least 50%?
> 
>> Haskell has no exception, it has Monads instead. Rust reuses Option and 
>> Result (Maybe and Either in Haskell) with great success.
> 
> For all my love to Haskell, I wouldn't consider it an example of a
> practical programming language. I mean, there aren't many projects
> written in Haskell of a size larger than GHC.
> 
>>> Why not make a trait BaseString and apply all the operations to it?
>> It's "heavier", in several ways.
>> [...]
>> In short, Slice is just a superior alternative.
> 
> I agree that it is conceptually simpler. But compare code, required to
> read one integer from a file in Python, C++ and Rust:
> 
> a = int(f.read_line())
> 
> int a;
> f >> a;

Your C++ example isn't checking for an I/O error and isn't even checking
that it succeeded at parsing an integer.

> let a: int = from_str(f.read_line().unwrap().as_slice().trim()).unwrap();

This isn't doing the same thing as the C++ code. The C++ code is reading
an integer from the stream, while this is allocating a string and then
converting.

An apples to apples comparison would read a string from the C++ API and
convert with std::stoi, or use a similar input API in Rust for streams
to avoid needless string conversions and noise.

The trim would also be unnecessary if you were using an API comparable
to the one the C++ code is using.

> Two unwrap's are caused by the lack of exceptions, as_slice is to
> convert String -> str, trim is because from_str doesn't skip
> whitespace (I suppose, the last one is non-essential).



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] How to find Unicode string length in rustlang

[Daniel Micay]

On 28/05/14 10:07 AM, Benjamin Striegel wrote:
> I think that the naming of `len` here is dangerously misleading. Naive
> ASCII-users will be free to assume that this is counting codepoints
> rather than bytes. I'd prefer the name `byte_len` in order to make the
> behavior here explicit.

It doesn't need to exist at all, because `as_bytes().len()` is available.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] dynamic memory allocations

[Daniel Micay]

On 21/05/14 09:19 AM, Zoltán Tóth wrote:
> Daniel Micay mailto:danielmi...@gmail.com>> wrote:
> 
> ... the default
> allocator, which is jemalloc right now.
> 
> 
> Rust's memory management is still under-documented in the manual. I have
> a question which have been bothering me for a while. I may have
> misunderstood something basic.
> 
> Jemalloc AFAIK synchronizes the allocations, as it is multithread-ready.
> However does Rust not use task-specific heaps? [I thought that most of
> the dynamic allocations happen in task-specific heaps.] For those is
> Jemalloc's synchronization not an unnecessary waste of processor time? 

Types like `Vec` and `Box` can be sent between tasks and `Arc`
can be shared so there's no task-local heap. It's true that a few types
like `Rc` are task-local but there would be no performance gain from
an extra layer. It would just create needless memory fragmentation.

jemalloc creates 4 arenas for every core (each with a lock) and assigns
threads to these arenas. It then has thread local caches on top of those.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev

Re: [rust-dev] owned pointer vs. owning pointer vs. owned box

[Daniel Micay]

On 20/05/14 07:41 PM, Liigo Zhuang wrote:
> Could you show us the memory layout of Box? Thank you!

The memory layout is just a pointer to a dynamic allocation with the
size of the value. Providing the dynamic allocation is up to the default
allocator, which is jemalloc right now.



signature.asc
Description: OpenPGP digital signature
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev