On 06/03/14 02:29 AM, comex wrote:
>
> Since things like use-after-free, buffer overruns, missing locks, etc.
> constantly affect real programs, I wouldn't focus on it too much.
It's possible to write non-nullable smart pointer types in C++ so that
the only safety issues come from explicit moves o
On Thu, Mar 6, 2014 at 1:38 AM, Patrick Walton wrote:
> Optimization of null pointer dereferences has resulted in security
> vulnerabilities in the Linux kernel:
That was not a case where the load was actually optimized away, only a
check following the load. In standard userland as well as moder
Optimization of null pointer dereferences has resulted in security
vulnerabilities in the Linux kernel:
http://lwn.net/Articles/342330/
I don't think it's responsible for C++ programmers not to consider the
undefined behavior of null dereference a real hazard.
Patrick
comex wrote:
>On Wed, M
*((int*)0): In theory, this is memory unsafe; In practical, this has been
exist for about thirty years, making many software system crash. But I
know, most C++ programmers don't consider it a big deal.
2014-03-06 13:06 GMT+08:00 comex :
> On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton
> wrote:
On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton wrote:
> Dereference of a null pointer is memory-unsafe due to being undefined
> behavior. You can't count on dereference of nullptr resulting in a load of
> address zero: the optimizer is free to (and often does) remove that load and
> any code foll
Dereference of a null pointer is memory-unsafe due to being undefined behavior.
You can't count on dereference of nullptr resulting in a load of address zero:
the optimizer is free to (and often does) remove that load and any code
following it. This means that, for example, clang will cheerfully
On 05/03/14 11:25 PM, comex wrote:
> On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann wrote:
>> Try the same in C++:
>>
>>
>> auto i = make_unique(1234);
>> auto j = std::move(i);
>> cout << *j << endl; // 1234
>> cout << *i << endl; // Segmentation Fault
>
> Note that a move out o
On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann wrote:
> Try the same in C++:
>
>
> auto i = make_unique(1234);
> auto j = std::move(i);
> cout << *j << endl; // 1234
> cout << *i << endl; // Segmentation Fault
Note that a move out of unique_ptr is guaranteed to leave the original
On Tue, 2014-03-04 at 23:54 -0300, Fernando Pelliccioni wrote:
>
> We still have the problem of dangling references.
>
>
> Any decent compiler can deal with this problem, and according to the
> Standard the implementations are encouraged to issue a warning in such
> a case.
> I don't know impleme
Am 05.03.2014 03:54, schrieb Fernando Pelliccioni:
>
> So, now, what is the difference between...
>
> // rust
> let i = ~1234;
>
> and
>
> // C++
> auto i = make_unique(1234);
>
> ?
>
> The Rust code is shorter, but perhaps, more illegible. I think it is
> matter of taste.
>
> But now, the real
You are only considering the simplest uses of references. Consider iterator
invalidation, deletion of the object referenced by the "this" pointer,
truncation of a vector containing an object to which references are live, etc.
C++ references are not memory safe and no compiler warnings can make t
Well, since comments are disabled in the blog, I will analyze the points
made in the article.
** Ownership **
int *dangling(void)
{
int i = 1234;
return &i;
}
First, the way it is written. Please!
This is not C++ ! (Well, it is C, therefore it is also C++, OK)
I think it is written so in
This is getting off topic but...
C++ has legitimate reasons (no modules, no jit) why it can't be
fast-building. Rust has much less. I really hope one day a JIT will be
supported to get REALLY fast turnaround times during development.
- Clark
On Tue, Mar 4, 2014 at 9:31 PM, comex wrote:
> On
On Tue, Mar 4, 2014 at 6:52 AM, Clark Gaebel wrote:
> fast-building
If only that were actually true...
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://mail.mozilla.org/listinfo/rust-dev
As someone looking strongly at rust for things i normally use c++ for, I'm
not switching for memory safety. When I need real performance (i.e. When
I'm likely to switch to c++), i frequently do a lot of unsafe things in
either language.
I was sold on rust because it's a "syntactically lightweight
On 3/3/14 11:00 PM, Nathan Myers wrote:
My concern is that the examples presented in tutorials must be
compelling to skilled C++ programmers. If we fail to win them over, the
whole project will have been a waste of time. The most skilled
C++ programmers know all too well what mistakes show up o
Hi everyone,
I am long time reader and follower of Rust. Great job with the design and
implementation.
On Mar 3, 2014 11:00 PM, "Nathan Myers" wrote:
> My concern is that the examples presented in tutorials must be
> compelling to skilled C++ programmers. If we fail to win them over, the
> whol
On 03/03/2014 09:18 PM, Kevin Ballard wrote:
On Mar 3, 2014, at 8:44 PM, Nathan Myers wrote:
There are certainly cases in either language where nothing but a
pointer will do. The problem here is to present examples that are
simple enough for presentation, not contrived, and where Rust has
the
> Incidentally, to the extent this is about a proposed document
> comparing Rust's safety to C++ in general
It's actually not: that's incidental. The idea is to communicate the core
ideas of Rust in 30 minutes or less. To give the reader an idea if they'd
like to pursue Rust further.
Memory safet
On Mon, Mar 3, 2014 at 11:44 PM, Nathan Myers wrote:
> C++ does allow a reference to last longer than the
> referent, and that's worth calling attention to.
Yeah... for memory safety I would consider a reference the same thing
as a pointer, although it helps in other cases such as null pointers
a
On Mar 3, 2014, at 8:44 PM, Nathan Myers wrote:
> On 03/03/2014 07:46 PM, comex wrote:
>> On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers wrote:
>>> It's clear that we need someone fully competent in C++ to
>>> code any comparisons. In C++, one is only ever motivated to
>>> ("unsafely") extract t
On 03/03/2014 07:46 PM, comex wrote:
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers wrote:
It's clear that we need someone fully competent in C++ to
code any comparisons. In C++, one is only ever motivated to
("unsafely") extract the raw pointer from a smart pointer when
only a raw pointer will
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers wrote:
> It's clear that we need someone fully competent in C++ to
> code any comparisons. In C++, one is only ever motivated to
> ("unsafely") extract the raw pointer from a smart pointer when
> only a raw pointer will do. This is exactly as likely
On Mon, Mar 3, 2014 at 8:17 PM, Nathan Myers wrote:
> (Arguably, BTW, the keyword should be "safe", because you are
> asserting to the compiler that it should consider what is being
> done there to be safe, despite any misgivings it may have, and
> challenging the reader to contradict it. But tha
I recently wrote a tool that helps with auditing unsafe blocks:
https://github.com/huonw/unsafe_ls
It lists all the unsafe blocks in a crate and prints the lines with the
actual unsafe actions on them, with a crude filter to omit FFI (and/or
only see FFI). This doesn't do anything intelligent
On 03/03/2014 05:54 PM, Patrick Walton wrote:
On 3/3/14 5:53 PM, Daniel Micay wrote:
On 03/03/14 08:19 PM, Steve Klabnik wrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets of C++ that
are more or less safe, but the lan
It's plain hyperbolic to call Rust's unsafe blocks something that leads to a
false sense of security. If you don't want your unsafe code to be reliant on
safe code, don't call that safe code, or be conservative and defend yourself
against it going wrong. Unsafe code should be simple and easy to
On 03/03/14 08:54 PM, Patrick Walton wrote:
> On 3/3/14 5:53 PM, Daniel Micay wrote:
>> On 03/03/14 08:19 PM, Steve Klabnik wrote:
>>> Part of the issue with that statement is that you may or may not
>>> program in this way. Yes, people choose certain subsets of C++ that
>>> are more or less safe,
When I first wrote this, there was a LARGE amount of discussion on HN.
Here's one particular subthread that seems relevant:
https://news.ycombinator.com/item?id=7052518
It includes a C++11 bit of code with uniq_pointer that crashes.
___
Rust-dev mailing
On 3/3/14 5:53 PM, Daniel Micay wrote:
On 03/03/14 08:19 PM, Steve Klabnik wrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets of C++ that
are more or less safe, but the language can't help you with that.
You can choos
On 3/3/14 5:51 PM, Daniel Micay wrote:
Smart pointers and destructors are no more unsafe in C++ than they are
in Rust. Rust makes moves and references safe, it doesn't do anything to
make a smart pointer implementation more safe.
It prevents you from misusing smart pointers and destructors to d
On 03/03/14 08:19 PM, Steve Klabnik wrote:
> Part of the issue with that statement is that you may or may not
> program in this way. Yes, people choose certain subsets of C++ that
> are more or less safe, but the language can't help you with that.
You can choose to write unsafe code in Rust too. T
On 03/03/14 08:41 PM, Patrick Walton wrote:
> On 3/3/14 4:32 PM, Daniel Micay wrote:
>> Type-checked lifetimes on references and type-checked move semantics are
>> examples of true safety improvements over C++. They are not a panacea as
>> they prevent expressing many safe patterns, even when the s
On 03/03/14 08:36 PM, Lindsey Kuper wrote:
>> On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik
>> wrote:
>>>
>>> Part of the issue with that statement is that you may or may not
>>> program in this way. Yes, people choose certain subsets of C++ that
>>> are more or less safe, but the language can't
On 3/3/14 4:32 PM, Daniel Micay wrote:
Type-checked lifetimes on references and type-checked move semantics are
examples of true safety improvements over C++. They are not a panacea as
they prevent expressing many safe patterns, even when the safety is
obvious to a human or a more complex type-ch
> On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik
> wrote:
>>
>> Part of the issue with that statement is that you may or may not
>> program in this way. Yes, people choose certain subsets of C++ that
>> are more or less safe, but the language can't help you with that.
On Mon, Mar 3, 2014 at 6:22
Then, you could show this in the article, using the "good" subset of C++.
Then people can choose.
On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik wrote:
> Part of the issue with that statement is that you may or may not
> program in this way. Yes, people choose certain subsets of C++ that
> are
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets of C++ that
are more or less safe, but the language can't help you with that.
___
Rust-dev mailing list
Rust-dev@mozilla.org
https://m
On 03/03/14 06:06 PM, Steve Klabnik wrote:
> Oh, Patrick, I slightly mis-read what you said. Yes, that was the intention.
>
>> I think official documentation shouldn't be directly trying to "sell" Rust
>> against other languages,
>
> While I agree, comparing against things we already know is a p
On Mon, Mar 3, 2014 at 8:06 PM, Steve Klabnik wrote:
> Oh, Patrick, I slightly mis-read what you said. Yes, that was the
> intention.
>
> > I think official documentation shouldn't be directly trying to "sell"
> Rust against other languages,
>
> While I agree, comparing against things we already k
Oh, Patrick, I slightly mis-read what you said. Yes, that was the intention.
> I think official documentation shouldn't be directly trying to "sell" Rust
> against other languages,
While I agree, comparing against things we already know is a powerful
way to learn. I _do_ think that we shouldn't
I originally wrote that because I also made a post to the rust-dev
mailing list, and I assumed that people may want to talk about it
there. Totally, brand-new threads weren't expected at this moment.
I'll take that out of the post.
___
Rust-dev mailing li
On 3/2/14 8:41 PM, Fernando Pelliccioni wrote:
What about "Feedback very welcome on the rust-dev mailing list or on
Twitter." ?
Oh, I didn't realize the blog post contained that. Well, I assume that
was soliciting feedback regarding using the post, or something derived
from it, as an official
Notice that there was a link to a two-month old thread on the list.
His email is in that...
On Sun, Mar 2, 2014 at 11:44 PM, Fernando Pelliccioni
wrote:
> I don't have the Steve's email address.
> Please could someone provide it.
> Thanks.
>
>
> On Mon, Mar 3, 2014 at 1:41 AM, Fernando Pelliccion
I don't have the Steve's email address.
Please could someone provide it.
Thanks.
On Mon, Mar 3, 2014 at 1:41 AM, Fernando Pelliccioni wrote:
> What about "Feedback very welcome on the rust-dev mailing list or on
> Twitter." ?
>
>
> On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton wrote:
>
>> On 3
What about "Feedback very welcome on the rust-dev mailing list or on
Twitter." ?
On Mon, Mar 3, 2014 at 1:38 AM, Patrick Walton wrote:
> On 3/2/14 8:34 PM, Fernando Pelliccioni wrote:
>
>> This is a misleading propaganda against C++. I think it's pure marketing.
>> I hope this code ugly C++ was
On 3/2/14 8:34 PM, Fernando Pelliccioni wrote:
This is a misleading propaganda against C++. I think it's pure marketing.
I hope this code ugly C++ was not on purpose.
I think it would be fair that you enable comments on the website so I
can show how to code in real C++. Do you dare to discuss se
This is a misleading propaganda against C++. I think it's pure marketing.
I hope this code ugly C++ was not on purpose.
I think it would be fair that you enable comments on the website so I can
show how to code in real C++. Do you dare to discuss seriously?
If the feedback is in a different place
48 matches
Mail list logo
