[rust-dev] RFC about int, uint, and 16-bit CPUs

Both Issue #14758 (Specify that int and uint are at least 32 bits on every CPU architecture) and Issue #9940 (rename `int` and `uint` to `intptr`/`uintptr`) call for RFCs. So RFC https://github.com/rus

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

On Tue, Jun 24, 2014 at 6:06 PM, Vadim Chugunov wrote: > > On Tue, Jun 24, 2014 at 5:41 PM, Daniel Micay >> wrote: >> >>> 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

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

Yeah. And would programmers also have to convert each literal, like in the Java-ish hashCode() example: result = (wint) 31 * result + (wint) areaCode; because adding a non-wraparound integer and a wraparound integer is ambiguous? Hey, it's "just" 5 more arithmetic operators. (A building architec

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

On Tue, Jun 24, 2014 at 11:58 AM, Daniel Micay wrote: > That's why I support adding attributes but turning wrapping on overflow > on and off for a scope. You can indicate whether wrapping is considered > correct in that scope, meaning you either expect it to wrap or you have > audited it (just as

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

On Mon, Jun 23, 2014 at 10:32 PM, Daniel Micay 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.

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

On Mon, Jun 23, 2014 at 1:49 PM, Daniel Micay wrote: > 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-integ

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

Apologies for adding heat to the discussion. The industry needs to make progress on security/safety-critical systems, and Rust does a great deal for that by bringing memory safety to a C/C++ alternative. This post about hardware traps for integer overflow is

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

OK. You folks made good points. How about if I retract "or obsolete" in favor of "or up for big change or not the tool for those purposes"? Maybe abort-on-overflow in suitable cases... On Sat, Jun 21, 2014 at 5:02 PM, Daniel Micay wrote: > On 21/06/14 07:55 PM, Benjamin Striegel wrote: > >> No

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

On Sat, Jun 21, 2014 at 4:07 PM, Daniel Micay 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 o

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

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) *obs

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

On Fri, Jun 20, 2014 at 5:36 PM, Gábor Lehel wrote: > > > > On Sat, Jun 21, 2014 at 1:37 AM, Jerry Morrison wrote: > >> >> On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel >> wrote: >> >>> >>> >>> >>> On Thu,

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

On Fri, Jun 20, 2014 at 2:07 PM, Gábor Lehel wrote: > > > > On Thu, Jun 19, 2014 at 9:05 AM, Jerry Morrison wrote: > >> Nice analysis! >> >> Over what scope should programmers pick between Gábor's 3 categories? >> >> The "wraparound is

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

Nice analysis! Over what scope should programmers pick between Gábor's 3 categories? The "wraparound is desired" category should only occur in narrow parts of code, like computing a hash. That suits a wraparound-operator better than a wraparound-type, and certainly better than a compiler switch.

Re: [rust-dev] Unified function/method call syntax and further simplification

On Sun, Oct 20, 2013 at 5:28 AM, Gábor Lehel wrote: > On Sat, Oct 19, 2013 at 10:52 PM, Patrick Walton wrote: > >> I think it's unfortunately too late to overhaul the language like this. >> This will require redesigns of all Rust code in existence. >> >> I do like unified function/method call syn

Re: [rust-dev] real-time programming? usability?

On Sat, Oct 19, 2013 at 2:36 PM, Tim Chevalier wrote: > On Sat, Oct 19, 2013 at 2:33 PM, Jerry Morrison wrote: > > > > So with a suitable library, real-time threads can avoid garbage > collection > > pauses. Can it enforce linking to this library for all the code it >

Re: [rust-dev] real-time programming? usability?

On Fri, Oct 18, 2013 at 11:02 PM, Daniel Micay wrote: > On Sat, Oct 19, 2013 at 12:45 AM, Jerry Morrison wrote: > >> >> On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay wrote: >> >>> On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison wrote: >>>> >>

Re: [rust-dev] real-time programming? usability?

On Fri, Oct 18, 2013 at 6:13 PM, Daniel Micay wrote: > On Fri, Oct 18, 2013 at 7:37 PM, Jerry Morrison wrote: >> >> >> (1) Rust has great potential for *real-time programming* as well as >> secure programming. Perhaps this just needs a library call to fork >>

Re: [rust-dev] real-time programming? usability?

On Fri, Oct 18, 2013 at 4:47 PM, Huon Wilson wrote: > On 19/10/13 10:37, Jerry Morrison wrote: > > > >- Use postfix syntax for pointer dereference, like in Pascal: > (~rect).area() becomes rect~.area() . That reads left-to-right with >nary a precedence mistake

[rust-dev] real-time programming? usability?

Hello! While reading the Rust tutorial I'm really excited to see a new programming language that can replace C/C++ for performance-critical programming. C/C++ is very entrenched but extremely tricky and getting more complicated with each revision. The world needs a replacement that's not so perilou