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 or
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_uniqueint(1234);
?
The Rust code is shorter, but perhaps, more illegible. I think it is
matter of taste.
But now, the real advantage is
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
On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann mneum...@ntecs.de wrote:
Try the same in C++:
auto i = make_uniqueint(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
On 05/03/14 11:25 PM, comex wrote:
On Wed, Mar 5, 2014 at 6:22 AM, Michael Neumann mneum...@ntecs.de wrote:
Try the same in C++:
auto i = make_uniqueint(1234);
auto j = std::move(i);
cout *j endl; // 1234
cout *i endl; // Segmentation Fault
Note that a move out of
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
On Wed, Mar 5, 2014 at 11:42 PM, Patrick Walton pwal...@mozilla.com 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
*((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 com...@gmail.com:
On Wed, Mar 5, 2014 at 11:42 PM, Patrick
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 com...@gmail.com
On Thu, Mar 6, 2014 at 1:38 AM, Patrick Walton pwal...@mozilla.com 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
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
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
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
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
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
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 say
On Mon, Mar 3, 2014 at 8:06 PM, Steve Klabnik st...@steveklabnik.comwrote:
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
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 powerful
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 st...@steveklabnik.comwrote:
Part of the issue with that statement is that you may or may not
program in this way. Yes, people choose certain subsets
On Mon, Mar 3, 2014 at 10:19 PM, Steve Klabnik st...@steveklabnik.com
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,
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 safety
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. The
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
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
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/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
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 Mon, Mar 3, 2014 at 8:17 PM, Nathan Myers n...@cantrip.org 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
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org 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
On 03/03/2014 07:46 PM, comex wrote:
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org 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
On Mar 3, 2014, at 8:44 PM, Nathan Myers n...@cantrip.org wrote:
On 03/03/2014 07:46 PM, comex wrote:
On Mon, Mar 3, 2014 at 10:17 PM, Nathan Myers n...@cantrip.org wrote:
It's clear that we need someone fully competent in C++ to
code any comparisons. In C++, one is only ever motivated to
On Mon, Mar 3, 2014 at 11:44 PM, Nathan Myers n...@cantrip.org 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
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 safety
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
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 pcwal...@mozilla.com 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
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 fpellicci...@gmail.com
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
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
fpellicci...@gmail.com 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,
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
38 matches
Mail list logo
