- Rust has the same memory problem as C and C++ - 25 Updates
| red floyd <no.spam@its.invalid>: Apr 25 06:27PM -0700 On 4/25/20 3:15 PM, Keith Thompson wrote: > is invalid C++. > A less common reason might be C code that uses C++ keywords as > identifiers. (I've occasionally done this deliberately.) And one highly unlikely scenario (May apply to C90 only): x = y //* divided by */ z; |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Apr 26 05:01AM +0200 On 26.04.2020 03:27, red floyd wrote: >> identifiers. (I've occasionally done this deliberately.) > And one highly unlikely scenario (May apply to C90 only): > x = y //* divided by */ z; Even more unlikely, that someone would use complex numbers in C. - Alf |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 26 12:25AM -0400 On 4/25/20 11:01 PM, Alf P. Steinbach wrote: ... > Even more unlikely, that someone would use complex numbers in C. <https://searchcode.com/?q=%22%3Ccomplex.h%3E%22&lan=28> |
| David Brown <david.brown@hesbynett.no>: Apr 26 12:23PM +0200 On 25/04/2020 20:36, Jorgen Grahn wrote: > their C code with the former and their C++ code with the latter. > The ability to use C libraries from C++ (without any glue) matters > though. Indeed. Mostly you want C /headers/ to be useable from C++, with the usual conditional extern "C" part. It's rare that you need to have the C implementation file be valid C++ (with the same semantics). I've had occasional customers ask that the C files be valid C++, in case they later want to change the files to being C++ - it is not an onerous requirement. But I don't think it is a common one. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 09:39AM +0200 Don't discuss with idiots. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 04:00PM +0200 > When someone uses the term "C/C++", he's usually referring to the > overlapping parts of those languages, as well as what both languages > share in terms of behavior. Such as for example memory allocation. And when you talk about security-concerns iterators of overloaded []-operators aren't safer than raw pointers for release-builds. |
| 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@cogsci.ed.ac.uk (Richard Tobin): Apr 19 09:29PM In article <chine.bleu-C2A2E3.08300419042020@reader.eternal-september.org>, >> https://simpleprogrammer.com/what-does-cc-mean/ >It's how spanish sailors answer orders. The motto of the French navy: a l'eau, c'est l'heure. -- Richard |
| 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. |
| 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. |
| Melzzzzz <Melzzzzz@zzzzz.com>: Apr 19 08:56PM > And that fact is sufficient to justify referring to defects of C/C++, > because both languages share those defects though their shared common > heritage. There is no choice. If language requires portion of code to be written in assembler that's not business. That is why ADA never took of ;) -- 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). |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 20 03:30PM +0200 Le 20/04/2020 à 15:05, Öö Tiib a écrit : > Operating systems accept raw pointers as parameters and return raw > pointers, usage of those is unsafe, and so operating system calls > remain unsafe whatever you do until these become marked safe. Again: From your high level language you never call the OS directly. You call a routine that calls the OS. That way you never leave the language safety, and it is the routine that calls the OS that uses the raw pointers, returning a high level object, that uses the raw pointers returned by the OS but it is protected by the language. |
| 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. |
| Ben Bacarisse <ben.usenet@bsb.me.uk>: Apr 20 04:28PM +0100 > (This especially if you follow recommended coding guidelines > in C. Like for example never using implicit casting between > incompatible pointer types but always making it explicit. A cast is an explicit conversion so "implicit cast" sounds odd to some people. You are referring, I think, to a conversion without a cast operator. > C++ doesn't allow implicitly casting between incompatible > pointer types while C does, but doing so in C is often frowned > upon in programming style guidelines.) C++ does not use C's definition of compatible types so there is no obvious and unambiguous meaning for this statement. C++ defines two kinds of type compatibility but neither is directly related to the rules about pointer conversions. However, C++ does allow some pointer conversions between types that would probably be considered "incompatible" by most reasonable meanings of the word. For example: struct s { int x; } s; void *p = &s; Of course you might mean that being able to assign the pointers is what you mean by "compatible" in C++, in which case, yes! -- Ben. |
| Juha Nieminen <nospam@thanks.invalid>: Apr 20 01:20PM > This paper compares Rust with an hypothetical language called C/C++. > There is no such language in existence As much as purists want to claim that C++ is its own independent programming language that's completely separate and independent from C, the fact is that in practice something like 99% of C is valid C++ as-is, without modification. (This especially if you follow recommended coding guidelines in C. Like for example never using implicit casting between incompatible pointer types but always making it explicit. C++ doesn't allow implicitly casting between incompatible pointer types while C does, but doing so in C is often frowned upon in programming style guidelines.) It can be argued that C++ is a mix of C and the additions that C++ brings to the table. While not all C programs are valid C++ without modification, as said the vast majority of them are (and the rest can usually be made valid C++ with minor corrections, with the exception of a few major modern C features that absolutely do not work in C++, such as VLAs.) When someone uses the term "C/C++", he's usually referring to the overlapping parts of those languages, as well as what both languages share in terms of behavior. Such as for example memory allocation. (In C++ the exact same memory allocation function can be used as in C. C++ also provides its own memory allocation keywords which don't differ in terms of memory management, only in terms of them calling constructors and destructors. Both languages also share the same caveats that memory can be leaked, the same memory freed more than once, freed memory accessed, and out-of-bounds memory also likewise accessed. (C++ may offer more tools to automatize memory management, but it doesn't remove the fact that those things can happen.) Thus I don't think it's unreasonable to use the term "C/C++". It doesn't refer to one singular programming language. It's referring to two related programming languages as a pair, which share similar behavior and features. |
| 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. |
| 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 |
| 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/ |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 20 01:23AM +0200 Le 19/04/2020 à 21:37, Jorgen Grahn a écrit : > 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 If you use the C containers library you do not have to either. I wrote that library and presented it to the C committee. They told me that C++ does that already. So, C was denied that path. |
| 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 |
| 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 |
| 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 . |
| Guillaume <message@bottle.org>: Apr 20 05:07PM +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. It also irritates me to no end when I see "C/C++". Still, that doesn't automatically mean the paper's content is worthless. You can assume that they are talking about the problems that are common to both C and C++. Yeah, still looks like HR bullshit, but hey. Anyway, I read it. It's not that bad. But to sum it up, conclusion is that the "unsafe" parts of Rust are as unsafe as C or C++. What a surprise. Not sure we learned a lot here. Now the question is, if Rust can't really be used in real-life projects without at least some parts written as "unsafe" code, the concern is valid. But I think the whole point is to use as little unsafe code as possible, and kind of isolate it. Whether the end result in a given application is objectively safer would be a more interesting study than what I read in this paper. |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 20 06:08PM +0200 Le 20/04/2020 à 16:02, Öö Tiib a écrit : > Demanding freelance Rust to have support for all of it safely at > high level is dishonest attempt to demand it to be born dead. Surely not. It is just a matter of doing it automatically. Given a .h file with the C prototypes of the OS API you can parse that and generate a rust definitions file, and generate automatically the interface functions. The only thing you need to do is a mapping from the C types to the Rust types. I have done that and is absolutely doable... |
| 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