- Rust has the same memory problem as C and C++ - 24 Updates
- The unintended consequences of the 'auto' keyword - 1 Update
jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 02:17PM +0200 The new language "rust" promised memory safety and efficiency, making for a great promise... that they can't keep. A recent paper shows that Rust has the same problems as C or C++. https://arxiv.org/pdf/2003.03296.pdf jacob |
Paavo Helde <eesnimi@osa.pri.ee>: Apr 19 03:39PM +0300 19.04.2020 15:17 jacobnavia kirjutas: > for a great promise... that they can't keep. > A recent paper shows that Rust has the same problems as C or C++. > https://arxiv.org/pdf/2003.03296.pdf This paper compares Rust with an hypothetical language called C/C++. There is no such language in existence, which makes the whole paper a bit suspect. |
"Öö Tiib" <ootiib@hot.ee>: Apr 19 05:42AM -0700 On Sunday, 19 April 2020 15:17:51 UTC+3, jacobnavia wrote: > for a great promise... that they can't keep. > A recent paper shows that Rust has the same problems as C or C++. > https://arxiv.org/pdf/2003.03296.pdf I am maybe misunderstanding what I read again but huh. Is it really article that states that stuff in Rust encapsulated in unsafe{ ... } is unsafe? Is it really meant to distribute FUD against Rust? Appearance of such clearly mud slinging articles has always indicated that target is doing far stronger than I thought and it is time to invest into it! |
jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 03:21PM +0200 Le 19/04/2020 à 14:42, Öö Tiib a écrit : >> A recent paper shows that Rust has the same problems as C or C++. >> https://arxiv.org/pdf/2003.03296.pdf > I am maybe misunderstanding what I read again but huh. No, it is simply that your evangelical positions are getting upset. > Is it really article that states that stuff in Rust encapsulated in > unsafe{ ... } is unsafe? Exactly. But why are those unsafe APIs necessary? Because they are essential. And that means that Rust has the same problems than C with usage after free() etc. Is it really meant to distribute FUD > against Rust? No, it is an investigation of Rust's claims and its FUD about C. > Appearance of such clearly mud slinging articles > has always indicated that target is doing far stronger than I > thought and it is time to invest into it! Evangelist position noted... |
jacobnavia <jacob@jacob.remcomp.fr>: Apr 19 03:24PM +0200 Le 19/04/2020 à 14:39, Paavo Helde a écrit : > This paper compares Rust with an hypothetical language called C/C++. > There is no such language in existence, which makes the whole paper a > bit suspect. I have often seen he/she for instance. And I never supposed that a "heshe" sex exists. The "/" is used as "either of" as you obviously know. Unable to say anything of value, you just utter nonsense. |
gazelle@shell.xmission.com (Kenny McCormack): Apr 19 01:28PM In article <r7hgqu$e23$1@dont-email.me>, >This paper compares Rust with an hypothetical language called C/C++. >There is no such language in existence, which makes the whole paper a >bit suspect. Very funny! Ha Ha Ha!!! Everybody knows what is meant by the term C/C++. Yes, even you. -- There are a lot of Wisconsin farmers right now who, despite having themselves voted for Trump, are now wishing that their state's electors had had the good sense to vote for the other candidate - thereby saving them from their current predicament. |
Richard Damon <Richard@Damon-Family.org>: Apr 19 09:31AM -0400 On 4/19/20 8:39 AM, Paavo Helde wrote: > This paper compares Rust with an hypothetical language called C/C++. > There is no such language in existence, which makes the whole paper a > bit suspect. But C and C++ are very related languages, so there IS a language family that can be described as C/C++, and there is a common core that is common between the two languages. C++ adds a number of features, that when used can abstract out may of the things that cause one class of memory errors, but at the same time adds a layer of complexity that might enable others. C++ also doesn't force you to use the abstractions that help eliminate some of the memory problems, but allows you to do the low level operations that open the door to memory access issues, and in fact the abstractions tend to be based on using those lower level operations, its just that the scope of those operations are tried to be kept smaller so it is hopefully easier to reason that it is being done correctly. |
Bart <bc@freeuk.com>: Apr 19 03:21PM +0100 On 19/04/2020 13:39, Paavo Helde wrote: > This paper compares Rust with an hypothetical language called C/C++. > There is no such language in existence, which makes the whole paper a > bit suspect. That hypothethical language to be supported by MS: https://code.visualstudio.com/docs/languages/cpp You might want to read here too: https://simpleprogrammer.com/what-does-cc-mean/ |
Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 19 03:55PM +0100 > for a great promise... that they can't keep. > A recent paper shows that Rust has the same problems as C or C++. > https://arxiv.org/pdf/2003.03296.pdf The first line of the summary: "Most memory-safety bugs are related to unsafe APIs or foreign function interfaces (FFIs)." An "unsafe API" is a technical term in this paper. It does not mean buggy Rust, it means calling a library that can't provide Rust's memory guarantees. -- Ben. |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 03:01PM > A recent paper shows that Rust has the same problems as C or C++. > https://arxiv.org/pdf/2003.03296.pdf > jacob Here is my spare time project in Rust about covid19: https://github.com/bmaxa/covid19report here is implementation of some binary trees: https://github.com/bmaxa/trees_rust I can tell you if rust closed possibility for low level programming it would be useless. They removed pointer arithmetic, and you have to cast pointer to integer add then cast back. Also you can implement it in library easilly :) -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Paavo Helde <eesnimi@osa.pri.ee>: Apr 19 06:04PM +0300 19.04.2020 16:24 jacobnavia kirjutas: >> bit suspect. > I have often seen he/she for instance. And I never supposed that a > "heshe" sex exists. The "/" is used as "either of" as you obviously know. "He/she" is used if there is no difference if there is a "he" or a "she". Here, regarding the topic of the paper (memory management) using slash would only have some merit if both sides of "either or" are at least somewhat similar. In reality, this is one of the areas where C and C++ differ the most, memory allocation in C++ does not resemble or behave anything like in C. To compare them to something without making distinction just shows full ignorance. |
Siri Cruise <chine.bleu@yahoo.com>: Apr 19 08:30AM -0700 In article <G7ZmG.124954$8W7.6293@fx13.am4>, > https://simpleprogrammer.com/what-does-cc-mean/ It's how spanish sailors answer orders. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 19 12:14PM -0400 On 4/19/20 8:39 AM, Paavo Helde wrote: > This paper compares Rust with an hypothetical language called C/C++. > There is no such language in existence, which makes the whole paper a > bit suspect. The term "C/C++" can be used correctly to refer to both C and C++ in a single statement. In particular, it can be correctly used to refer to things that are true in the common subset of C and C++. C and C++ are sufficiently closely related that their common subset is very nearly (but not quite) the same as C. That paper uses the term a grand total of three times: "To elaborate, the culprits of buffer overflow bugs in Rust are very similar to those in C/C++, which generally involve both logical errors and arbitrary pointer operations that are allowed only by unsafe Rust." While C++ provide tools that can be used to make it slightly easier to avoid buffer overflows than C, it continues to support every feature of C that makes it vulnerable to buffer overflows. "Like C/C++, using unsafe APIs has no memory-safety promise, making Rust programs vulnerable to memory-safety bugs." Is he wrong about that? Does either language provide that kind of promise? If so, what precisely is the wording of the promise. "Since Rust has no magic in preventing logical errors, such as boundary checking, using unsafe APIs is as vulnerable as C/C++ in buffer overflow." While C++ has many features that make is less susceptible to such problems than C is, but C++ still supports every feature of C that that comment refers to. |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 04:17PM > overflow." While C++ has many features that make is less susceptible to > such problems than C is, but C++ still supports every feature of C that > that comment refers to. Rust is ok regarding programming errors. Compiler is very picky and descriptive. If you don't use * I don't know how you can get buffer overruns in Rust. Rust eg is compiler error if you use object that is being moved and destructors are not called for moved objects... -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Richard Damon <Richard@Damon-Family.org>: Apr 19 01:59PM -0400 On 4/19/20 11:04 AM, Paavo Helde wrote: > differ the most, memory allocation in C++ does not resemble or behave > anything like in C. To compare them to something without making > distinction just shows full ignorance. Actually, at the fundamental level they do use very similar methods. Most C++ implementations map new()/new[]() to malloc() (and delete to free). The big difference is that much C++ code pushes those operations to basic classes (smart pointers and collections) which C doesn't. Yes, many of the flaws they talk about are hard to do in C++ than in C *IF* you are using the higher level abstractions (correctly). C++ first does not require you to use them, and there is still plenty of C++ code using somewhat naked pointers with all those issues, and a lot of people will also use some of those feature, but use them wrong and the just think they are safe from the problems. |
Paavo Helde <eesnimi@osa.pri.ee>: Apr 19 09:29PM +0300 19.04.2020 19:14 James Kuyper kirjutas: > sufficiently closely related that their common subset is very nearly > (but not quite) the same as C. That paper uses the term a grand total of > three times: Regarding memory allocation the common subset of C and C++ is almost empty. Of course, C++ (almost) supports the C-style memory allocation code, but it's still C code, not C++, because no sane C++ programmer will allocate memory this way. > While C++ provide tools that can be used to make it slightly easier to > avoid buffer overflows than C, it continues to support every feature of > C that makes it vulnerable to buffer overflows. Yes, C++ supports unsafe code, this is a major selling point because of C back-compatibility. But apparently, so does Rust. Using unsafe code or unsafe API-s in any language (which supports this) is unsafe, so why select two such languages and then pretend they are a single language? The main reasons of buffer overflow bugs in C are: - allocating a too short local buffer because dynamic allocation is such a hassle. - allocating a "big enough" dynamic buffer in advance because resizing a buffer is such a hassle, and getting the needed size wrong. - losing the actual size of the buffer because it was calculated from another variable at the point of allocation, or the variable holding the size gets mixed up or modified while passed to the usage point. None of the above applies to C++ where allocating, resizing and retrieving the size of a std::vector is trivial. > programs vulnerable to memory-safety bugs." Is he wrong about that? Does > either language provide that kind of promise? If so, what precisely is > the wording of the promise. I do not argue that C or C++ cannot be used in unsafe ways. I argue that in the regard of memory safety topics they are two totally different languages and should not be referred to as a single language. > overflow." While C++ has many features that make is less susceptible to > such problems than C is, but C++ still supports every feature of C that > that comment refers to. Yes, C++ supports writing unsafe C code. Howevere, C++ also supports much safer ways to write code which are routinely used by any half-decent C++ programmer, so in regard to the memory safety issues these languages are very different and should not be referred to as a single language. An especially valid point about C++ is that using the safer approaches like std::vector does not decrease the performance of the application, contrary to Rust if I have understood correctly. |
Daniel P <danielaparker@gmail.com>: Apr 19 12:27PM -0700 On Sunday, April 19, 2020 at 2:29:49 PM UTC-4, Paavo Helde wrote: > size gets mixed up or modified while passed to the usage point. > None of the above applies to C++ where allocating, resizing and > retrieving the size of a std::vector is trivial. But algorithms that write to output iterators can override the bounds of your container, unless using "checked iterators" or back insert iterators. Daniel |
Jorgen Grahn <grahn+nntp@snipabacken.se>: Apr 19 07:37PM On Sun, 2020-04-19, Daniel P wrote: >> retrieving the size of a std::vector is trivial. > But algorithms that write to output iterators can override the bounds of your > container, unless using "checked iterators" or back insert iterators. Or you can accidentally use an invalidated iterator, and so on. Maybe the main benefit of C++ in this area is that you're not tempted to use fixed-size buffers for things with no fixed max size. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:04PM +0100 On Sun, 19 Apr 2020 21:29:36 +0300 > An especially valid point about C++ is that using the safer approaches > like std::vector does not decrease the performance of the application, > contrary to Rust if I have understood correctly. But going back to your "this paper compares Rust with an hypothetical language called C/C++. There is no such language in existence, which makes the whole paper a bit suspect", what I think is more suspect is (i) jacobnavia's opening conclusion, expressed in the heading to these posts, that "Rust has the same memory problem as C and C++", and (ii) the referenced paper's implicit "No" conclusion to the self-posed question "Memory-Safety Challenge Considered Solved?" Both propositions are hyperbolic. If you use the unsafe subset of Rust, which you have to label explicitly as unsafe in your code, then (surprise, surprise) it is unsafe. However if you do not explicitly do so, then unsafe memory usage shouldn't compile. Yes, C++ when used correctly is indeed more safe than C. However memory safety is not enforced through its type system: it instead forms a usage pattern. In Rust memory safety is enforced: that is what Rust's affine/linear type system is supposed to be all about (together with thread safety). That I think is a significant advance. Whether it is sufficient of an advance in practice to make Rust a genuine competitor to C++ in the future is something that time will tell. The paper concluded that "Most of these bugs are related to unsafe APIs or FFIs. It means that Rust is very effective in preventing memory-safety bugs if using safe Rust only. On the other hand, using unsafe Rust is as risky asother programming languages that mainly relies on the developerto prevent memory-safety issues." This is not a revelation of a great new truth. The Rust community would say exactly the same, and do in their documentation. They would however be concerned by the "Most of". If memory safety bugs exist in safe Rust code, then there is a bug in Rust which they would want to solve. |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 08:16PM > thread safety). That I think is a significant advance. Whether it is > sufficient of an advance in practice to make Rust a genuine competitor > to C++ in the future is something that time will tell. I think that Rust is fine replacement for C++, only thing is that it is not used much yet. But, C++ is industrial language and has many implementations and tool support. It is long way before it can be usefull as C++ in industry. > however be concerned by the "Most of". If memory safety bugs exist in > safe Rust code, then there is a bug in Rust which they would want to > solve. Memory safety is not problem in Rust, problem is that it has no pointer arithmetic, no tail call recursion optimisation and no way to disable bounds checking ;) Check this out: scimark2 gcc: /.../forth/sci >>> ./scimarkgcc ** ** ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark ** ** for details. (Results can be submitted to pozo@nist.gov) ** ** ** Using 2.00 seconds min time per kenel. Composite Score: 2626.67 FFT Mflops: 2079.86 (N=1024) SOR Mflops: 2039.68 (100 x 100) MonteCarlo: Mflops: 514.70 Sparse matmult Mflops: 3005.40 (N=1000, nz=5000) LU Mflops: 5493.73 (M=100, N=100) now Rust: ~/.../rust/scimark2 >>> ./target/release/scimark2 ±[●][master] ** ** ** SciMark2 Numeric Benchmark, see http://math.nist.gov/scimark ** ** for details. (Results can be submitted to pozo@nist.gov) ** ** ** Using 2.00 seconds min time per kernel Composite Score: 1962.53 FFT Mflops: 1744.24 (N=1024) SOR Mflops: 1284.64 (100 x 100) MonteCarlo Mflops: 1431.66 Sparse matmult Mflops: 2621.44 (N=1000, nz=5000) LU Nflops: 2730.67 (M=100, N=100) This is of course mine interpretation, but if anyone can do better? just see this: impl<T> Slice<T> { fn new(t:&mut [T])->Self { Slice{ptr:t.as_mut_ptr(),size:t.len()} } } impl<T> IndexMut<usize> for Slice<T> { fn index_mut(&mut self,i:usize)->&mut T{ // assert!(i<self.size); unsafe {&mut *((self.ptr as usize + i*mem::size_of::<T>()) as *mut T)} } } impl<T> Index<usize> for Slice<T> { type Output = T; fn index(&self,i:usize)->&T{ // assert!(i<self.size); unsafe {&*((self.ptr as usize + i*mem::size_of::<T>()) as *const T)} here is whole proggy: https://github.com/bmaxa/scimark2rust -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:35PM +0100 On Sun, 19 Apr 2020 20:16:41 GMT > Memory safety is not problem in Rust, problem is that it has no > pointer arithmetic, no tail call recursion optimisation and > no way to disable bounds checking ;) It will never be able to implement tail call elimination effectively, because it uses the same memory management techniques in its type system as well written C++ code does by good practice, namely destructors. Destructors are not in tail position. In consequence, tou need garbage collection for effective iterative recursion. That, I imagine, is why Rust describes itself as an "expression language" rather than a functional language (it clearly is very heavily influenced by ML in other respects). A safe language shouldn't try to eliminate bounds checking or permit pointer arithmetic either. If you want to do that, confess it openly, label your code explicitly unsafe and take everything that is coming to you if you get it wrong. > Check this out: [snip] > This is of course mine interpretation, but if anyone can > do better? > just see this: [snip] I don't write Rust code. I am merely interested in its type system (as are a number of other languages, now). |
Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 19 09:39PM +0100 On Sun, 19 Apr 2020 21:35:15 +0100 > Destructors are not in tail position. Err, only the last destructor is in tail position and the recursive call is not. |
Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 08:40PM > [snip] > I don't write Rust code. I am merely interested in its type system (as > are a number of other languages, now). Heh in 2013 or so I submitted patch in Rust compiler to fix inheritance in Vtable bug :P -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala |
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 19 04:53PM -0400 On 4/19/20 2:29 PM, Paavo Helde wrote: >> three times: > Regarding memory allocation the common subset of C and C++ is almost > empty. In C, memory can be allocated three ways, statically, automatically, and dynamically. C provides four functions for dynamic memory allocation malloc(), free(), realloc(), calloc(). Every memory allocation feature of C is also a feature of C++, so the common subset is the same as the entirety of C's memory allocation features. While that set is small, I can't see any justification for calling that set almost empty. If it is almost empty, then C's features for memory allocation are almost empty. Would you be willing to accept that assertion? ... >> C that makes it vulnerable to buffer overflows. > Yes, C++ supports unsafe code, this is a major selling point because of > C back-compatibility. I was addressing only the reasonableness of using "C/C++" when writing a document comparing those languages with Rust. I know nothing about Rust, and have no interest in it, and in particular, no interest in discussing how it compares with C/C++. >> either language provide that kind of promise? If so, what precisely is >> the wording of the promise. > I do not argue that C or C++ cannot be used in unsafe ways. That's not what he's saying - he's saying that C and C++ can both be used in the same unsafe ways. That's certainly true, since you can write well-formed C++ code that looks and behaves essentially the same as the unsafe C code. ... > Yes, C++ supports writing unsafe C code. And that fact is sufficient to justify referring to defects of C/C++, because both languages share those defects though their shared common heritage. |
James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 19 12:22PM -0400 On 4/18/20 4:53 PM, Vir Campestris wrote: >> and know how to deal with it. > Interesting. I think I count myself as experienced - I've been writing C > and C++ for nearly 40 years - and yet it's never bitten me. I didn't say it was a big problem, either. > auto minus = -plus; > results in a 32 bit (or more!) size for minus is to me just another > reason not to use auto where I can avoid it. Well, the key reason why the integer promotions are generally not a serious problems is that they are always value-preserving (unlike the usual arithmetic conversions, where a negative value can sometimes end up being converted to an unsigned type). That's what makes those optimizations legal. Still, there is one situation where the integral promotions can be problematic. Expressions of unsigned type whose valid values are all representable as 'int' will get promoted to a int. In itself that's not a problem, but it can result in unexpected use of signed arithmetic on values that started out as unsigned. That's why I so surprised to see someone complain about the integral promotion of int16_t to int; I'd be much less surprised to see a complaint about uint16_t being promoted to int. |
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment