- Rust has the same memory problem as C and C++ - 23 Updates
- [Jesus Loves You] Inspirational woman - 1 Update
- Sausages - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 20 09:39AM +0200 Don't discuss with idiots. |
| 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. |
| 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. |
| 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... |
| 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 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 |
| 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. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 20 02:23AM -0700 On Sunday, 19 April 2020 16:21:47 UTC+3, jacobnavia wrote: > >> 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. What is my evangelical position? > > Is it really article that states that stuff in Rust encapsulated in > > unsafe{ ... } is unsafe? > Exactly. But why are those unsafe APIs necessary? World is full of unsafe APIs. Without ways to access operating systems or other modules in your computer a programming language is just a toy in its own sandbox and not a tool. That is obvious but somehow some morons want to leave impression that Rust claims differently. > Because they are essential. And that means that Rust has the same > problems than C with usage after free() etc. It has, nowhere is said that Rust by some wonder fixes MS Windows API somehow. Just part of your own code can be safe. Claiming differently is straw man building. > Is it really meant to distribute FUD > > against Rust? > No, it is an investigation of Rust's claims and its FUD about C. These were straw-man claims attributed to Rust and now it is fight with those self built straw-men. Rust hasn't claimed that calls marked unsafe are safe. What is Rust's FUD about C? > > has always indicated that target is doing far stronger than I > > thought and it is time to invest into it! > Evangelist position noted... How am I evangelical about Rust? I have barely had time to try it few times for nothing serious. My impression of it is that it is immature tool but interesting. Your article was crap, live with it. It is surprising for me that Rust already deserves such low attacks. |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 20 12:05PM +0200 Le 20/04/2020 à 11:23, Öö Tiib a écrit : > Your article was crap, live with it. It is > surprising for me that Rust already deserves such low attacks. Have you even read that article? No. It is "crap". That is enough to discard it... how easy! I cite the paper: <quote1> This paper studies the question by surveying the bug reports collected from two public datasets, Advisory- db and Trophy-cases, which contain all existing CVEs (common vulnerability and exposures) of Rust. We manually analyze each bug and extract their memory-safety issues and culprits. Our results show that buffer overflow and dangling pointers are still the major memory-safety issues in Rust, and most culprits are related to unsafe Rust. Such security issues reveal that the security cost of Rust to support unsafe functions is high. 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. However, the culprits of dangling pointers in Rust have unique patterns, especially those related to the vulnerability of Rust's borrow checker and lifetime checker. Based on these findings, we further suggest two directions to improve the resilience of Rust against dangling pointers, including recommending the best practice of some APIs to program developers, as well as approaches to enhancing the borrow checker and lifetime checker. Our work intends to raise more concerns regarding the memory-safety promise of Rust and facilitates the maturity of the language. <end quote> Just "crap" of course. The point here is that to achieve the announced speed of C++ or C you add to the language an "unsafe" feature. The whole undertaking is then tainted with that problem! How would you solve that? What lessons could be used from the proposals for Rust to the patterns of buffer overflows in C or C++? That would need a rational discussion and a bit of effort from your part. It is not as easy as just dismiss this work as CRAP without a single rational argument. That is why I classify your attitude as "evangelist" since NO ARGUMENTS ARE ADVANCED but just "CRAP"... Incredible! |
| "Öö Tiib" <ootiib@hot.ee>: Apr 20 04:00AM -0700 On Monday, 20 April 2020 13:05:18 UTC+3, jacobnavia wrote: > > surprising for me that Rust already deserves such low attacks. > Have you even read that article? > No. I have, two times. It is crap but it wasn't only thing that I wrote. You did chose not to respond to my points elaborating why it is crap. Were you afraid? Screaming now instead? > Just "crap" of course. The point here is that to achieve the announced > speed of C++ or C you add to the language an "unsafe" feature. The whole > undertaking is then tainted with that problem! So you discarded my response and now even quote that crappy straw-man building how the Rust's unsafe API meant for communicating with other modules in your computer can be misused for making memory-safety defects? No one has *ever* denied that. It was named "unsafe" for purpose. Surprised? Who is evangelical here? :D Pathetic. > How would you solve that? Solve what? That the world still needs hordes of software developers after Rust like it did need before? There are no way to solve that. But reducing pointless, hidden illusions that lurk everywhere, every feature full of explicitly said out undefined behaviors plus couple defined behaviors that do something surprising for majority is good idea to reduce indeed. Rust attempts, maybe fails maybe succeeds future will tell. Mud slinging shows that it is getting dangerously close. > single rational argument. That is why I classify your attitude as > "evangelist" since NO ARGUMENTS ARE ADVANCED but just "CRAP"... > Incredible! Your debating style isn't inviting to rational discussion. It is erasing responses to dodge those, then screaming dogmas and lying. It looks like you are going foaming-from-mouth-mad there instead, sorry. |
| jacobnavia <jacob@jacob.remcomp.fr>: Apr 20 02:16PM +0200 Le 20/04/2020 à 13:00, Öö Tiib a écrit : > You did chose not to respond to my points elaborating why it is crap. > Were you afraid? Screaming now instead? You have posted 2 articles in this thread: 1: 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! 2: In your second message, you do not put forward any arguments but just vague dismissals. For instance: I asked you: > But why are those unsafe APIs necessary? You answer: <quote> World is full of unsafe APIs. Without ways to access operating systems or other modules in your computer a programming language is just a toy in its own sandbox and not a tool. That is obvious but somehow some morons want to leave impression that Rust claims differently. <end quote> The "some morons" qualifier is surely me, of course. That is why I didn't even answer that. But OK, let's go in depth to your "argument". If your new language accepts inline assembler, raw pointer usage, and other goodies you are doing the same thing as C is doing for the sake of PERFORMANCE! It is absolutely NOT necessary, as you say, to use raw pointer in your program to acces the operating system facilities as everyone here knows. You can use the APIs of the operating system by providing an interface to the raw OS calls that use bound checked arrays and hide the raw pointer within containers and other language constructs. Such a way would be 100% safe but it would take a 0.1% performance hit. But Rust wants to take over C so it must offer at least the same speed, and THERE IS THE WRONG DESIGN DECISION! At the end Rust has the worst of both worlds because its insistence on raw performance and sacrificing security to raw performance as C or C++ do. Then, you learn a new language for nothing. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Apr 20 01:22PM +0100 On Mon, 20 Apr 2020 12:05:07 +0200 jacobnavia <jacob@jacob.remcomp.fr> wrote: [snip] > part. It is not as easy as just dismiss this work as CRAP without a > single rational argument. That is why I classify your attitude as > "evangelist" since NO ARGUMENTS ARE ADVANCED but just "CRAP"... Actually, the arguments have been explained to you by at least 3 people now. The problem is that you have failed to understand the paper, which is largely vacuous. That is evident in your original posting and in your subsequent responses. You need to get off your high horse, get a little less excited, and actually think about it before posting. The point you have failed to understand is that unless operating explicitly in unsafe mode Rust is memory safe. That is a significant improvement over C and C++. Of course if you choose to interface with C code using Rust's FFI, then your code is only as safe as your C code. And if you explicitly choose to use unsafe mode in Rust, which can be used to subvert Rust's safety guarantees, then your code is only as safe as your ability to write type-unsafe code. That is not a new revelation. You can deduce this by going to the Rust site and reading its manual. The authors of the paper could have done the same. It definitely does not mean, as you claim, that "Rust has the same memory problem as C and C++", which frankly is a ludicrous summary of the issues. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 20 06:05AM -0700 On Monday, 20 April 2020 15:16:33 UTC+3, jacobnavia wrote: > <end quote> > The "some morons" qualifier is surely me, of course. That is why I > didn't even answer that. But OK, let's go in depth to your "argument". It was indeed accusation since you seem to act like caught on sin with it. > If your new language accepts inline assembler, raw pointer usage, and > other goodies you are doing the same thing as C is doing for the sake of > PERFORMANCE! Screaming lies does not make those truths. Raw pointer usage and inline assembler are commonly unneeded "goodies". I see those extremely rarely used even in C++ code bases despite pile of undefined behaviors of C++ tries to leave no other way out to achieve something defined at some places. The main "goodie" from "unsafe" of Rust and its prime purpose is need to interface with unsafe code and modules of third parties and operating systems. You can keep running from that, brave sir Robin. > You can use the APIs of the operating system by providing an interface > to the raw OS calls that use bound checked arrays and hide the raw > pointer within containers and other language constructs. 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. > Such a way would be 100% safe but it would take a 0.1% performance hit. > But Rust wants to take over C so it must offer at least the same speed, > and THERE IS THE WRONG DESIGN DECISION! :D Why to scream such indoctrinated dogmas? 0.1% does matter next to nowhere. I have couple times had my algorithms rewritten again in Java and/or JavaScript for about 300-400% performance loss since performance was sufficient anyway. More important was scalable time- complexity while usage of mix of languages in project was perceived as inconvenient fragility. Java and JavaScript are unsafe as whole unlike Rust. > At the end Rust has the worst of both worlds because its insistence on > raw performance and sacrificing security to raw performance as C or C++ > do. Then, you learn a new language for nothing. It is just life of engineer to study new tools. If all would sit and mourn every of the promising tools and technologies that have come and gone then there would be whole lake of pointless tears. Rust can fail but the idea of it is anyway very impressive, worth to work on. And your clumsy mud-slinging attacks that so pathetically miss the point of its "unsafe" make it certainly stronger. |
| 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. |
| 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. |
| 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. |
| "Öö Tiib" <ootiib@hot.ee>: Apr 20 07:02AM -0700 On Monday, 20 April 2020 16:30:53 UTC+3, jacobnavia wrote: > 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. But that is pure lie. Name me high level language that has support to typical I/O like gyroscopes, GPS input, touch gestures, cameras, microphones, speakers and so on inbuilt? No language comes even close. The most mundane things like the std::filesystem have become available on Apple platforms only recently. And this is C++ with millions invested per year by every platform vendor and Apple is maker of *major*, *large* platforms. Demanding freelance Rust to have support for all of it safely at high level is dishonest attempt to demand it to be born dead. And it is funny how you run from that and erase my replies stating it. Why you behave as someone who is caught on crime? :D |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Apr 20 10:23AM -0400 On 4/20/20 9:20 AM, Juha Nieminen wrote: > 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.) <pedantic>A cast is a particular piece of syntax. That syntax in the source causes the implementation to generate code which implements the corresponding conversion. That syntax is not always required in order for the conversion to occur. When that is the case, it's called an implicit conversion, not an implicit cast - because it isn't a cast without that syntax, but it is still a conversion.</pedantic> Your wording could be interpreted as implying that incompatibility is not a barrier to C pointer conversions. In fact, in most cases it is a barrier. Such a conversion is allowed only if one of the two types is void*. Many people consider this an advantage - creating that advantage was one of the purposes behind the invention of "void*", though Bjarne clearly disagreed. Those people write programming style guidelines that reflect that opinion. |
| 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. |
| 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. |
| 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... |
| cdalten@gmail.com: Apr 20 06:04AM -0700 > bad times, even when she had given up. > We all need that rope she talks about. > -- Jesus might love you. But everyone else thinks that you're an asshole. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Apr 20 12:37AM +0100 Sausages. That is all. /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| 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