Herb Sutter on increasing safety in C++
Herb Sutter, chair of the ISO C++ standards committee, writes about the current problems with writing secure C++, and his personal opinion on next steps to address this while maintaining backward compatibility.
If there were 90-98% fewer C++ type/bounds/initialization/lifetime vulnerabilities we wouldn't be having this discussion. All languages have CVEs, C++ just has more (and C still more); so far in 2024, Rust has 6 CVEs, and C and C++ combined have 61 CVEs. So zero isn't the goal; something like a 90% reduction is necessary, and a 98% reduction is sufficient, to achieve security parity with the levels of language safety provided by MSLs [memory-safe languages]… and has the strong benefit that I believe it can be achieved with perfect backward link compatibility (i.e., without changing C++'s object model, and its lifetime model which does not depend on universal tracing garbage collection and is not limited to tree-based data structures) which is essential to our being able to adopt the improvements in existing C++ projects as easily as we can adopt other new editions of C++. — After that, we can pursue additional improvements to other buckets, such as thread safety and overflow safety.
Posted Mar 12, 2024 19:51 UTC (Tue)
by xav (guest, #18536)
[Link] (102 responses)
Posted Mar 12, 2024 21:10 UTC (Tue)
by atnot (subscriber, #124910)
[Link] (96 responses)
I think given sufficient motivation and functional governance processes, it would be perfectly possible to get C++ to a better point. There's a bunch of proposed extensions for both C and C++ that do a lot with just attributes already. That won't be as pretty of a solution as something like Rust, but people are very happy to use tools that rely on extra annotations in languages like python already because it's just a huge benefit in not writing bugs.
So if the institutional will to seriously tackle this is there now at a language level that's great. It remains to be seen if it can overcome the dysfunctional governance processes, but it definitely helps.
Posted Mar 12, 2024 21:21 UTC (Tue)
by khim (subscriber, #9252)
[Link] (95 responses)
C++-the-language can do that, too. This all works only if people are willing to do something. And C++ developers are not willing to even accept the fact that they are not supposed to write programs that trigger UBs. What else can be done if developers are not even willing to to follow the rules of the language that they are using? Dysfunctional governance is minor issue, the complete refusal to even entertain the idea that people may decide to write some rules and then, gasp, actually obey them… that's unfixable.
Posted Mar 12, 2024 21:34 UTC (Tue)
by ms-tg (subscriber, #89231)
[Link] (90 responses)
I read this “subset of a superset” proposal as a path to a C++ version that rejects code which disobeys a stricter standard.
Did you read it differently?
Posted Mar 12, 2024 21:47 UTC (Tue)
by khim (subscriber, #9252)
[Link] (88 responses)
I don't see that problem even being acknowledged as such, let alone being addressed. It starts with the assumption that everyone would strive to do the right thing and people would just agree to do something voluntarily. Safety doesn't work like that. If you couldn't weed out the worst offenders and kick them out (like what Rust does) then nothing else really matters. It doesn't mean that you should go around and ban offenders by dozens, no. And tools that help to catch problems (like Miri) also matter. But if you proclaim that I don’t want C++ to limit what I can express efficiently then you immediately should say what do you plan to do to people who would abuse that power. Because there would be abusers and you either do something about them… or you don't. If you don't plan to do anything about abusers then the whole thing just simply falls apart, it wouldn't work. And if you do plan to do something then I want to know what do you plan to do, because that's the biggest C/C++ plague by far: yes, the fact that inexperienced developer may introduce security issue by accident is problematic, but compared to the fact that some developers like to do that because they think they have that right… honestly, I have no idea what can be done there except for creating entirely new language (be it Carbon, Rust or Zig) and trying to keep such persons under control from the beginning.
Posted Mar 13, 2024 6:56 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (2 responses)
Posted Mar 13, 2024 9:23 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
Sure, but why is this even matters? Obscure crate which no one uses don't affect the security of the whole ecosystem all that much. And there are tools like cargo geiger, cargo vet and others that help one to keep their own codebase healthy. That's more than C++ world have, but the important thing is not even tools, but the understanding that the goal, itself, is worth pursuing. I don't see an understanding among many C++ developers. You don't see questions “Why might UB be bad in a deployed and fully isolated environment?” being discussed on Rust forums (except when preparing a talk about Rust in front of a bunch of C++ programmers). Just like you don't see discussions about why is it good idea to follow the traffic code among the drivers. They may lament the fines or badly installed traffic lights, but the “clever” C/C++-style idea “I know that neighbour better than these stupid guys that have drawn these road surface marking and thus just ignore them” is not something that is seriously considered as normal topic.
Posted Mar 13, 2024 11:22 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link]
It matters because you think you're writing safe code and you are not.
Posted Mar 13, 2024 7:30 UTC (Wed)
by intelfx (subscriber, #130118)
[Link] (10 responses)
Just let me clarify this: you use a blog post by one of Rust's founders in which he _laments_ the intolerant and nasty response of the broader Rust community to certain technical issues with a certain project as a reason to _celebrate_ this kind of response and suggest that it is the _only_ right thing to do?
For the sake of Rust's future, I hope you are not actually representing that community's values.
Posted Mar 13, 2024 9:08 UTC (Wed)
by khim (subscriber, #9252)
[Link] (9 responses)
Absolutely. This was the blog post which made me accept Rust. The rules have to be enforced, or they don't work. Without drastic actions takes sometime everyone would declare himself (or herself) “special” and thus rules breakage would become the norm (broken windows theory in practice). Linux had Linus with his infamous tantrums, Rust have these “nasty responses”. They have hope. You can get much further with a kind word and a gun than you can with a kind word alone. And no, that not the only thing to do. There are also education, reviews, forums and many other things. Kicking out every violator would be akin to using a gun without a kind word. And yes, I picked that article precisely because it was written by one of guys in the Rust community who likes to use “a kind word”. Of course you start with a kind words, sure. But if they are repeated again and again for year? And then ignored? Then it's time to pick that proverbial gun and use it. I represent large enough fraction. Which is critical for the success of the whole campaign. Steve may not like it and yes, it's always sad to see when bright and knowledgeable developer (genuinely bright and knowledgeable, no sarcasm here) is kicked out of the community, but without strict enforcement rules have no meanings. And I just couldn't see anything like that in a C++ world. There discussions happen for years, even decades, about inappropriateness of doing many “bad” things, yet there are lots of people who declare that they are doing nothing wrong and it's some other developers who have to do something. Which is justified by the fact that it's really hard, almost impossible to detect all these “bad” things (which is true, to some degree), but then, if rules are not enforced… does it even matter how many of them are there and if what they are, precisely if people just ignore them? In fact I suspect Herb Sutter actually understands that, too, that's why cppfront exists: it's an attempt to create a new C++, C++ reborn… and then people that would adopt it may, hopefully, be convinced to follow the rules. That's the good plan and if not for Rust it would have had a chance of success. But today that niche of “better, but incompatible, C++” is already occupied by Rust. This lowers success chances significantly, but don't make them nil: there are enough C++ developers who are jealous of Rust and hate it so deeply that cppfront may yet even find enough of them to succeed. But would there be enough of them to keep that whole house of cards from collapsing? Only time would tell.
Posted Mar 13, 2024 10:05 UTC (Wed)
by dvrabel (subscriber, #9500)
[Link] (7 responses)
Posted Mar 13, 2024 10:23 UTC (Wed)
by khim (subscriber, #9252)
[Link] (6 responses)
There are lots of middle ground. And sure, they are important, too. But rite of passage for any growing community is precisely that situation: what do you do to someone who refuses to follow the rules and “middle ground” doesn't work? Either community (any community!) accepts that not everyone may be reformed and then it have a chance to grow and yet still uphold the rules. Or it doesn't have that capability and then it either have to remain small or it would fall apart under it's own weight. Simply because beyond certain point you reach the stage where you have members which couldn't be “reformed” no matter what. And you have to do something about that. If we are talking about the countries then usual final form is physical execution or life imprisonment. In most other cases ostracism is enough. It's tool of the last resort, but it's important to have it.
Posted Mar 13, 2024 13:19 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Unfortunately, there are people who join communities with the DELIBERATE AIM of destroying them, because they disagree with them. For example militant atheists sending their kids to religious schools, and then complaining that their kids are being indoctrinated.
If someone else pushes you into an existential crisis, are you going to kill, or are you going to let yourself be killed. It's as black-and-white as that, sometimes ...
Cheers,
Posted Mar 13, 2024 22:48 UTC (Wed)
by dvrabel (subscriber, #9500)
[Link] (4 responses)
I don't think your attitude is going to encourage many people to look positively at the rust community. You might think you're doing it a service, but a community is a group of people first and software second.
Posted Mar 13, 2024 23:19 UTC (Wed)
by khim (subscriber, #9252)
[Link] (3 responses)
Wasn't my intent. And for the community to prosper you need both missionaries who bring new people in the community by preaching virtues of something (be it Emacs or Rust) but also inquisitors who expels (or, in it's final meaning of the word, executes) people who are violating the norm. Inquisitors are rarely well-liked, but without them community stops being capable of sustaining itself. Nope. We live in the world where “bad” software is increasingly capable of not just causing financial harm but to directly kill people, too… why should we treat it like we treat guns, then?
Posted Mar 14, 2024 0:37 UTC (Thu)
by pizza (subscriber, #46)
[Link] (2 responses)
Historically, Inquisitors significantly accelerate the downfall of the very community they supposedly serve.
Posted Mar 14, 2024 8:25 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
In other words, "inquisition" is more-or-less the exact opposite of what happened (continues to happen) in Rust … right?
Posted Mar 16, 2024 3:40 UTC (Sat)
by himi (subscriber, #340)
[Link]
I'm surprised that I haven't seen the paradox of tolerance mentioned yet - that's always seemed the most apt way of thinking about this kind of thing. A community that wants to maintain tolerant norms /has/ to be intolerant of intolerance, or the intolerance it tolerates will eventually destroy it; tongue twister aside, the same logic will apply to tolerance of certain other kinds of community norms. For a language community that's focused so heavily on safety, both in the language design /and/ the community norms, I'd argue it's entirely reasonable for the community to be intolerant when it comes to flagrant breaches of those norms - accepting those breaches, particularly in a well-known and widely used low-level library, would present a real danger of destroying the norms entirely.
Posted Mar 13, 2024 12:14 UTC (Wed)
by sb (subscriber, #191)
[Link]
It seems to me that you're just safety-washing your newfound zealotry here. This is nothing new of course; the software industry has always had its various cults, each with its own brand of religious fervour.
Posted Mar 13, 2024 17:25 UTC (Wed)
by ms-tg (subscriber, #89231)
[Link] (5 responses)
> Safety doesn't work like that. If you couldn't weed out the worst offenders and **kick them out** (like what Rust does [1]) then nothing else really matters.
The linked story is about Nikolay Kim, the original author of the Actix actor and web frameworks in Rust. And it is true that, after multiple loud community "uproars" over the use of unsafe code patterns in Actix and allegations that they would be unsound, my recollection is that he announced that he was quitting open source altogether, not just Actix [2].
However this is not the end of the story.
Three days after the initial quitting announcement (Jan 17-20, 2020), and after some folks reached out empathetically to recognize the single maintainer burden and reality of burnout, the original author changed course and appointed new maintainers [3], leading to a project that appears to be in pretty healthy shape today, and still doing pretty well on benchmarks [4].
Original author appears to continue to be active in open source Rust development [5], including a new project Ntex, "a powerful, pragmatic, and extremely fast framework for composable networking services for Rust" [6]
@khim I don't provide this perspective to take away from your point, that a language ecosystem community needs to "care enough" about soundness and safety for any changes to happen in actual practice.
But I want to point out that "kicked out" is not, to my knowledge today, an accurate picture of how the Rust community responded to this situation, and I think that is all for the better.
[1] https://steveklabnik.com/writing/a-sad-day-for-rust
Posted Mar 13, 2024 17:43 UTC (Wed)
by khim (subscriber, #9252)
[Link] (4 responses)
I think it's pretty accurate description of the situation. That “kick out process” was invented in Ancient Greece and AFAICS it was implemented as literally is it's possible to implement it in this day and age: Nikolay Kim was kicked out from his own project and related community and was forced to either join a different one or build something. Which is what he did. You may say that he is still part of the larger Rust community, but given the fact that ntex is just quite literally 100 times less popular than actix-web… if that is not called a “kick out” then what would you call a valid “kick out”?
Posted Mar 15, 2024 13:02 UTC (Fri)
by ms-tg (subscriber, #89231)
[Link] (3 responses)
Hmm. Digging a level deeper, ntex actually appears to be a fork of actix-web, with the idea of continuing its previous usage of unsafe code patterns to “win” the TechEmpower benchmarks (apparently by gaming many of them) [1].
Doesn’t it feel a bit more accurate to say that actix-web *forked*?
Mainline Actix seemingly went with the community of its users and prioritized soundness and reduction of unsafe code patterns over placing first in artificial benchmarks.
Original author forked ntex, which appears to retain a small following and seems to prioritize demonstrating absolute highest performance in benchmarks over reduction in unsafe code patterns?
Again, how does it seem more accurate to use the ostracism metaphor rather than a fork?
[1] https://www.reddit.com/r/rust/comments/v7slt3/using_ntex_...
Posted Mar 15, 2024 14:54 UTC (Fri)
by khim (subscriber, #9252)
[Link] (2 responses)
Do you even know what ostracism word even is? And how was it conducted in an Ancient Greece? Just go and read, damn it! Original author was expelled from the community by vote of the majority and was forced to leave and go into some other place. Just open the Wikipedia and read it: The person newly ostracised had ten days to leave the city. If he attempted to return, the penalty was death. The property of the man banished was not confiscated and there was no loss of status. After ten years, he was allowed to return without stigma. That is the original implementation of ostracism procedure! What have happened to Nikolay Kim is as close to original procedure as it was conducted in Ancient Athens as one may imagine! I'm not even sure if someone would have tried to recreate the procedure just for the sake of showing how it may work in a modern world there would be anything to change! Fork is different, when fork is happening (like e.g., when FreeBSD was worked and NetBSD was create or when Sodipody was forked and InkScape was created) then some group of people leaves and creates a new thing that is fork of the original. Here we have the exact opposite: the principal author of the whole thing was kicked out because community felt he doesn't do what community think he is supposed to do! The previous closest case when something that have happened is probably when NetBSD project have kicked out Theo de Raadt and he went on to create OpenBSD. Only it was for [almost] the exact opposite reason: Theo de Raadt had some ideas about how to make things more secure that clashed with the other member.
Posted Mar 15, 2024 16:19 UTC (Fri)
by sdalley (subscriber, #18550)
[Link] (1 responses)
Us OCD types do find it hard to let things go. But usually, we don't really know the people or the situation close-up. Making determined last stands on hills like these just adds to the din and is highly tedious to those who are in the vicinity.
Just sayin'. Have a nice weekend.
Posted Mar 15, 2024 16:51 UTC (Fri)
by sdalley (subscriber, #18550)
[Link]
Apologies to those who suffer from the medical condition known as OCD. I used the term carelessly. It's not a fun condition, at all...
Posted Mar 15, 2024 16:33 UTC (Fri)
by paulj (subscriber, #341)
[Link] (65 responses)
This was some guy's own project. He had nothing to do with core Rust. His project wasn't some core Rust project. He was some guy who'd written something for himself. He put it on Github. Others found it useful, evidently. And then, simply cause he just didn't want to dance to the tune of the self-entitled, toxic whingers that - unfortunately - like to go out of their way to belittle and demean people who have done nothing to them but *generously* _given them and everyone the fruits of their hard labour_, he /really/ got belittled, demeaned, insulted and attacked by said toxic crowd.
Really, the lesson here is Rust has some toxic people around it.
Posted Mar 15, 2024 16:36 UTC (Fri)
by paulj (subscriber, #341)
[Link]
However, arguments predicated on "Rust has a better community" might not be well-founded if they depend on that particular example.
Posted Mar 15, 2024 16:49 UTC (Fri)
by mb (subscriber, #50428)
[Link] (63 responses)
Maintaining something that people depend on is a responsibility. It does not matter, if it's for free or not. If he doesn't want to be criticized for his work or can't handle it, he should not publish it.
That's how free software works.
And yes: "I don't care, please fork my project, if you don't like my decision to use unsafe code" is a legitimate answer to such feedback.
Posted Mar 15, 2024 17:06 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (24 responses)
> Publish something and get feedback. That includes positive and negative feedback.
Agreed - what do you expect?
> And yes: "I don't care, please fork my project, if you don't like my decision to use unsafe code" is a legitimate answer to such feedback.
Except. According to paulj that's NOT what happened. They didn't fork his project, they stole it. Strong words, maybe? But they SHOULD have forked it. Quite probably with the guy's blessing. They shouldn't have expelled him from his own project. That's just "not nice" (TM).
Cheers,
Posted Mar 15, 2024 17:28 UTC (Fri)
by mb (subscriber, #50428)
[Link] (23 responses)
Maybe you want to read this?
To me that reads more like: "One driver on the wrong side of the road? No! Thousands!"
Posted Mar 15, 2024 23:41 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (22 responses)
How else would you describe driving the original author out?
> I guess many people then also stole my old projects that I don't maintain anymore and I stepped back from.
There's a big difference between taking over an abandoned project, and muscling in on a project that the creator is actively working on.
Even your own quote supports paulj's claim that the author was "driven out". This project does NOT appear to be an abandoned project.
I've been there done that - I had a project taken over by someone else. Okay, I couldn't find time to work on it, this other guy did, and while I didn't like what he did I abide by "he who writes the code, calls the tune". But if it was this guy's project, and he was actively working on it, then I don't think "stealing" is wrong word for forcing him out.
Cheers,
Posted Mar 15, 2024 23:55 UTC (Fri)
by mb (subscriber, #50428)
[Link] (1 responses)
Renewal.
Posted Mar 16, 2024 22:11 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
Cheers,
Posted Mar 16, 2024 0:28 UTC (Sat)
by khim (subscriber, #9252)
[Link] (19 responses)
No one ever did that. The author refused to play by rules. And when pressure have reached the boiling level, instead of doing the sensible thing, he decided to destroy everything. Later he acquiesced and instead of pulling QB64-style collapse just transferred maintainership to the people who do play by rules. It was abandoned at some point. By it's author. Only after that happened discussion about continuing maintainership by other people started. The hope was always that he would decide to take rules seriously, not that he would abandon it's own (and quite successful) project, but, apparently, for him benchmark games were more important than safety.
Posted Mar 16, 2024 10:57 UTC (Sat)
by paulj (subscriber, #341)
[Link] (18 responses)
That you and mb think that kind of behaviour is acceptable, indeed you appear to be _celebrating_ it, suggests the "Rust community" has learned _nothing_ from that episode - so far as your comments are representative.
Posted Mar 16, 2024 11:06 UTC (Sat)
by mb (subscriber, #50428)
[Link] (12 responses)
I just disagree with you whether this case *is* abuse or bullying.
Posted Mar 16, 2024 22:15 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (9 responses)
That is quite clear that he was bullied - words like "unsafe shitstorm"?
Classic troll behaviour - to argue thing, and claim articles support you when in fact they say the complete opposite.
The fact other people found his project useful, does not give them the right to demand he change his priorities to suit them. If they want to fork it to achieve their personal objectives, then fine. That they think it acceptable to abuse him for disagreeing with them is not.
Cheers,
Posted Mar 16, 2024 22:34 UTC (Sat)
by mb (subscriber, #50428)
[Link] (8 responses)
I actually read the article and also the communication he did on github.
Posted Mar 17, 2024 0:40 UTC (Sun)
by paulj (subscriber, #341)
[Link] (7 responses)
Also, given this was a personal project of his, and (AFAIK) he was doing this for his own enjoyment and fun, how can you characterise it as "unprofessional"?
You are projecting your own notions of what /you/ like for /your/ projects, onto the _personal_ time of other authors of Free Software, and you are _inventing_ obligations for said other Free Software authors that do not exist. They _do not exist_ in the licence, nor is it in any way sane to think that someone publishing some of their work as Free Software somehow encumbers them with /obligations/ to write the code the way /random others/ _demand_.
If you want to call the tune, pay the piper. Get a support contract. Pay them money. Put food on their table. _Then_ you have a _small_ and /limited/ right to expect something in return.
Posted Mar 17, 2024 0:43 UTC (Sun)
by paulj (subscriber, #341)
[Link]
That user has an *obligation* to be _polite_, and thankful. Especially if they havn't contributed a thing to said author.
Posted Mar 17, 2024 7:30 UTC (Sun)
by mb (subscriber, #50428)
[Link] (5 responses)
Has already been posted here.
> If you want to call the tune, pay the piper.
So people who contribute their free time for the removal of unsafe code must pay money so that their pull request gets handled professionally?
> onto the _personal_ time of other authors
Do you realize that this is also true for the rejected contributors and the users?
Posted Mar 17, 2024 12:09 UTC (Sun)
by paulj (subscriber, #341)
[Link] (4 responses)
See? Just fork, and be thankful. How is that hard? How _anything but that_ the right answer?
In particular, how is "Launch a campaign of abuse, to pressure the author into withdrawing from their own, personal project" acceptable?
What khim calls "ostracism" is implementable only through online bullying in an online world.
Posted Mar 17, 2024 12:29 UTC (Sun)
by mb (subscriber, #50428)
[Link] (3 responses)
>Launch a campaign of abuse, to pressure the author
Please read the authors responses to the PRs.
Posted Mar 17, 2024 12:33 UTC (Sun)
by paulj (subscriber, #341)
[Link] (2 responses)
Posted Mar 19, 2024 22:10 UTC (Tue)
by ms-tg (subscriber, #89231)
[Link] (1 responses)
2019 - Originally rejected fix PRs that explain and remove UB or other soundness issues
2018 - Original response to "why 100 uses of unsafe without clear documentation of safety"
I make no guarantee that these are the best examples, just a few I turned up.
Also please note, for contrast, the many fixes that went in just after the maintainer transition on Jan 20 2020, e.g.
Posted Mar 20, 2024 10:37 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Anyway, let's leave it.
Posted Mar 17, 2024 0:34 UTC (Sun)
by paulj (subscriber, #341)
[Link] (1 responses)
However, the author's own characterisation of matters is that he received "abuse". Even summaries of what happened by /critics/ of the author that I find on reddit suggest "some" of the other criticisms (e.g. in reddit discussions) went too far. There is a suggestion that there were even "death threats" - by 2nd or 3rd hand sources I have read, I don't know how true.
Just in this LWN discussion - long after the fact, in a much more sober and considered and forum than reddit - the author has been described as an "offender", as "someone who refuses to follow the rules", and that "to do something about that". Admittedly just one commentator here, though it seems you also approve of the notion that "something" must be done to ostracise such people and expel them.
Again, we are talking about a guy who just published his /own/ software, to his /own/ Github account - who had nothing to do with any core Rust group. Who did nothing but give the world a high-performance web framework. And, events since (the author still maintains the code, now under another name, and it apparently beats the pants off the "community" [neutered?] version) suggest that this author actually knows something about making code perform.
I think the bullying was totally unacceptable, and I think some of the views being posted in this article in support of the campaign to "ostracise" an author of free software - i.e. effectively condoning abuse and bullying, even if you claim to be against it - are a stain on Free Software.
Posted Mar 17, 2024 15:45 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
Comparing his _personal_ project to the city of Athens is indeed way beyond ridiculous. If the core Rust group wants to "ostracize" disrupting people then great. But policing the entire Internet is not ancient Greece; it's the KGB.
Having to share space and live together is hard. The beauty of "forking" and the Internet in general is: there is an infinite amount of space and freedom available. No need to artificially import limitations from the real world.
BTW this is why the decision to remove "thumbs down" on social media and other sites is so good. If you don't like something, explain why and create something better in _your_ space and try to convince users and get more "thumbs up". Don't come and pollute other people's space.
Posted Mar 16, 2024 11:12 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Actually Rust community have learned which things work and which things don't work. Which means it has a chance to survive. But I guess the majority of people in the first world just don't understand how things work. Well, coming collapse of EU, rivers of blood in Europe and smaller pools of the same substance in US would reeducate them… I just wish there was an easier way to teach people… but it looks like nothing else works. If you portray the demands not to disable security alarms and to keep fuses functional “abuse” then I don't even know what to say. The analogue to what Kim did would be creation of bridge without safety rails or building major mall without regard to regulations which demand that it should survive an eathquake. If you do that in real world you may easily go to jail, in virtual world Kim just had to step down and he still got keep it's own fork which he may still play with… how is that “abuse”?
Posted Mar 16, 2024 11:20 UTC (Sat)
by atnot (subscriber, #124910)
[Link] (3 responses)
I feel like this sort of thing is an area where there is a huge disconnect between people actually involved with the rust project or any projects of note (like e.g. Steve Klabnik, who condemned this strongly in the blog post linked) and a certain genre of poster especially prevalent on places like reddit, where this kicked off. It's really the usual contept culture stuff we see all day in all programming communities[1], but it's really disheartening to see from a community that I feel should be able to do better. It doesn't help that people feel emboldened and righteous by how genuinely important of a cause memory safety is either.
[1] If anyone hasn't read it yet: https://blog.aurynn.com/2015/12/16-contempt-culture/
Posted Mar 16, 2024 12:19 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
How do you know there's a disconnect? I'm pretty sure that Steve is genuine in his grief. He is just not the person who would do things like that. I don't think he ever objected to what Kim is doing, publicly or privately. But how do you know what others are thinking? I know for the fact that many of them would be fired if they would say what Redditers easily say… and you want to say that people placed in this position are the ones words of whom we should trust? I consider Reddit posts closer to what people actually think: on Reddit people may say things without fear of retaliation because Reddit doesn't give others an easy way to use DIE department of speaker's company to silence said speaker. Yet Reddit does give an option to silence people who stray out of the line. And if you go against the majority you would be silenced. But that wouldn't be because one person who hates your guts used the evidence that your are not “tolerant enough” against you. Thus that easy threat: be nice even to the guys who may destroy your community or else you would be fired? That's not possible on Reddit. Or LWN for that matter. But that's only not possible for people who keep their real identity separated from your Reddit (or LWN) identity. Once someone knows who you are… DIE departments are always watching. These are the real uncontrollable Inquisition that accelerate the downfall of the modern society that they supposedly serve. You couldn't trust a word of anyone who is under threat to DIE from his words. P.S. That's why I celebrate what Rust achieved there. 20 or maybe even 10 years ago it wouldn't have been an achievement. But today, when voices of everyone who may act as authority and stop language abuse easily are forcibly silenced… to do what Rust community managed to achieve is not easy.
Posted Mar 16, 2024 22:23 UTC (Sat)
by Wol (subscriber, #4433)
[Link]
So you're happy celebrating a witch hunt. The ONLY thing this guy did wrong was to publish his pet project in the hope that other people would find it useful. And he got loads of abuse from people who thought what he was trying to achieve was conpletely unacceptable. I sure as hell hope you enjoy being a witch-finder. Because hell is where witch-finders are likely to end up.
Unfortunately, this is just the "me me me" politically correct and toxic side of Free Software. I just wish we could kick that out ...
Cheers,
Posted Mar 17, 2024 6:29 UTC (Sun)
by corbet (editor, #1)
[Link]
Posted Mar 15, 2024 17:51 UTC (Fri)
by pizza (subscriber, #46)
[Link] (6 responses)
Wow, that's some serious victim blaming entitlement BS.
> That's how free software works.
*ahem*
"[the work is provided] on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE."
The author owes everyone else precisely *nothing*. Anyone using that work is not entitled to support, fixes, updates, or anything more than the completely-as-is bits they already have in front of their faces.
> And yes: "I don't care, please fork my project, if you don't like my decision to use unsafe code" is a legitimate answer to such feedback.
The fact that the "Rust Community" didn't accept that "legitimate answer" is the *entire point* of this sub-thread. Indeed, many consider this piled-on grief to be a laudable feature of "Rust Culture".
Posted Mar 15, 2024 18:01 UTC (Fri)
by mb (subscriber, #50428)
[Link] (5 responses)
That was not necessary, because he left the project before that was necessary.
>The author owes everyone else precisely *nothing*.
Yes. It's his right to step down.
Where's the problem?
Posted Mar 15, 2024 20:42 UTC (Fri)
by pizza (subscriber, #46)
[Link]
"stepping down" is a deliberate act of removing yourself from some position (or otherwise giving up some sort) of power.
Saying he(?) "has the right to step down" already presupposes something that was never a given; namely that he owed anyone anything to begin with.
> Where's the problem?
The fact that he was expected (if not outright demanded) to take _any_ sort of action or effort for someone else's benefit to begin with.
Posted Mar 15, 2024 23:45 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (3 responses)
But it should have been his FREE CHOICE to step down.
> Where's the problem?
He didn't WANT to step down.
Cheers,
Posted Mar 16, 2024 0:03 UTC (Sat)
by mb (subscriber, #50428)
[Link] (2 responses)
No. It absolutely should not.
If this is a project that many people depend on, then the author should not have the free choice to continue the project at his own choice and force, if the majority disagrees.
It is his free choice to fork the project.
Just the the "stupid majority" go. What's the problem?
Posted Mar 16, 2024 22:32 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
If this is a project that many people depend on, then they were bloody idiots to depend on a project by someone who did not share the same values they did.
If you fnd a project that does 90% of what you want, and that extra 10% is unacceptable to the project owner then it on YOU to FORK it, not seize it by force.
At the end of the day, the very Register article you pointed us at said it was mob rule. The behaviour shown here was completely unacceptable, made even worse by the fact there was a perfectly acceptable, friendly, alternative.
Cheers,
Posted Mar 17, 2024 2:21 UTC (Sun)
by paulj (subscriber, #341)
[Link]
If someone wrote some code, and lets you use it for free, and you think it should be written differently, or some things could be done different or added: Suggest it, very nicely, as a "might be nice...". And if they disagree, well, say "Thanks for the code!". Your choices after that (if you're a not self-absorbed, toxic, ingrate) are to see if you can /pay/ the author, or fork and do it yourself (or pay someone else).
Don't be the self-absorbed, toxic, ingrate, who thinks that there are some holy coding rules, passed down from the great bearded hacker in the sky, the transgression of which justifies against a (non-profit, coding for fun) transgressor a campaign of "ostracism" - which the recipient is very likely to perceive as abusive.
Especially when these rules are not even in the damn compiler. Hell, the "transgressor" is explicitly /conforming/ to the rules of the language, as checked by the compiler.
Posted Mar 15, 2024 18:15 UTC (Fri)
by paulj (subscriber, #341)
[Link] (27 responses)
In particular, you need to reflect to what extent your thinking _enables_ the toxicity that many Free Software authors and maintainers are subjected to, that I have in mind in my comment above.
Posted Mar 15, 2024 18:36 UTC (Fri)
by mb (subscriber, #50428)
[Link] (26 responses)
Being responsible to your users does *enable* toxicity? Really?
And yes, I think that I as a free software maintainer am responsible for delivering a good product to my users.
So, very clearly: Yes. Publishing a free software project that has many users depending on it comes with a maintenance responsibility.
Even if they don't pay me a Dime.
Posted Mar 15, 2024 20:46 UTC (Fri)
by pizza (subscriber, #46)
[Link] (12 responses)
No. What is toxic is users *demanding responsibiity* when it's been *explicit* from the beginning that they do not have any grounds to expect it.
What is toxic is fostering a culture that says that making those demands (without appropriate compensation) is somehow okay.
Posted Mar 15, 2024 20:53 UTC (Fri)
by mb (subscriber, #50428)
[Link] (11 responses)
Just stop publishing things, if you don't care about users. It really is that simple.
Posted Mar 15, 2024 21:57 UTC (Fri)
by pizza (subscriber, #46)
[Link] (10 responses)
You keep assuming that users are somehow owed "care" by some sort of divine right. [1]
If you want "care" then you must supply equivalent "compensation" [2]
And it really is that simple.
> And most important, don't complain, if all users tell you that you are wrong. Because most likely you are wrong.
You've been in this field far too long to truly believe that.
(And just in case you are actually serious, if the user has a different use case or expectations to what the author claimed to the software would provide, then yes, the user is *wrong*. But remember, this particular bruhaha was about the *style of implementation* of completely legal Rust code.)
[1] I've written software to sovle a problem my partner was having. That was the only user I "cared" about.
Posted Mar 15, 2024 22:46 UTC (Fri)
by mb (subscriber, #50428)
[Link] (9 responses)
You know what? The longer I have been in this field, the more I care about code correctness and about what other people say. I want to learn from other people. I know that I am wrong most of the time.
>if the user has a different use case or expectations to what the author claimed to the software would provide, then yes, the user is *wrong*.
That is something I absolutely disagree with.
I as the author do reserve the option to not do anything about it and keep the project as-is.
In free software there is no immediate "wrong" or "right". It's just that the "right" solution will continue to live. If I am actually right and 1000 people are wrong, then at the end I will succeed.
But unnecessary unsafe code won't succeed, IMO.
Posted Mar 16, 2024 22:40 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (1 responses)
> That is something I absolutely disagree with.
Screw. Meet hammer.
Just because many users think Excel is a database, just because clueless idiots think that F1 racing cars would be an excellent fast delivery vehicle, doesn't make them right.
Actually, that F1 example is pretty apt. The project was designed for SPEED, not heavy lifting. Just because idiots want to use a racing car to deliver 44-tonne loads, words fail me ...
Cheers,
Posted Mar 16, 2024 22:43 UTC (Sat)
by mb (subscriber, #50428)
[Link]
That is not a base for further discussion.
Posted Mar 17, 2024 14:40 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (6 responses)
If the user thinks they're “right” but the maintainer of the code disagrees, it is the user's privilege to fork the code. The user is not entitled to have the maintainer change the code, at no charge, to conform to the user's wishes, and the user most certainly does not get to hijack the original project by driving away the original maintainer.
The principle of free software is, you scratch your own itches. Scratching other people's itches, particularly for free, is entirely optional (even though some free-software maintainers take satisfaction from that, and if that happens, good for those other people). In fact, the whole idea behind free software in the first place is putting other people in a position where they can scratch their own itches and don't need to rely on anyone else to scratch those itches for them.
Posted Mar 17, 2024 14:52 UTC (Sun)
by mb (subscriber, #50428)
[Link] (5 responses)
Popular projects don't live in a vacuum. If a maintainer of a popular project makes decisions that many users disagree with, then the maintainer will have to live with the feedback.
Please go and take a look at the code. Some uses of unsafe were completely ridiculous.
>The principle of free software is, you scratch your own itches
That is only a very small part of it.
Posted Mar 17, 2024 16:45 UTC (Sun)
by paulj (subscriber, #341)
[Link] (4 responses)
I am sceptical that it is possible for an author to leave responses to PRs/CRs made on their own personal project that could justify a campaign of negative comments against them. A campaign apparently that included "death threats" and which the author felt included "abuse". How can an unreasonable response by an author to PRs on their own project justify anything _else_ but "Thanks for the code, I'll make those changes somewhere else myself"?
You keep saying those responses exist, can you show them?
The level of entitlement that is implied by what you are saying is completely off the scale.
Posted Mar 17, 2024 16:57 UTC (Sun)
by mb (subscriber, #50428)
[Link] (3 responses)
>included "death threats"
You surely have a link to that?
Posted Mar 18, 2024 15:07 UTC (Mon)
by paulj (subscriber, #341)
[Link] (2 responses)
"You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help. ... I started to receive complaints that docs are not updated and i have to go fix my shit. Encouraging. ... You felt betrayed after you put so much effort and then to hear all this shit comments, even if you understand that that is usual internet behavior."
https://github.com/fafhrd91/actix-web-postmortem
That is authoritative text on how the author felt. And I think we were all aware of that text before we started this discussion.
Now, your counter to this is that /his/ responses to the criticisms he received were unprofessional. I have asked for an example, twice now I think, but you've not given any, other than to claim I can find it if I look. Well, from reading around forums on this, the most heinous charge I can find levelled against the author is that he called a PoC change in a comment "boring":
http://web.archive.org/web/20200116231317/https://github....
I don't think /any/ response by an author, on their own issue tracker for their own personal project, could justify a campaign of "ostracism" (which in an online comment pretty much implies lots of toxic comments being left on various forums; from the target's own issue trackers, to reddit, etc. - i.e. abuse and bullying). I especially think that "this patch is boring" does not justify it.
The correct response is "Thanks for all your hard work on this code, and your generosity in open sourcing it - appreciate it, and I'll see about making my desired changes in my own version". Always really. At least, for anyone who is not a toxic ingrate.
If you had another comment in mind by the author, feel free to link to it.
Posted Mar 18, 2024 17:16 UTC (Mon)
by mb (subscriber, #50428)
[Link] (1 responses)
So? Maybe they are right?
> "nobody wants to do home work"
Also applies to the author.
> "and read docs and think a bit and very few provide any help."
Also applies to the author.
But it's Ok to have a different opinion.
> I have asked for an example, twice now I think, but you've not given any,
I said twice, that this has been posted already. I am not going to search the discussion threads for you.
> At least, for anyone who is not a toxic ingrate.
Do you realize that your definition of "toxic ingrate" also applies to yourself?
Posted Mar 18, 2024 18:13 UTC (Mon)
by corbet (editor, #1)
[Link]
Posted Mar 15, 2024 20:48 UTC (Fri)
by paulj (subscriber, #341)
[Link] (12 responses)
As a user of another project, you have 0 right to expect its author or maintainer has any responsibility towards you - unless you've some other contract with them.
Posted Mar 15, 2024 20:59 UTC (Fri)
by mb (subscriber, #50428)
[Link] (11 responses)
Being wrong is fine. But don't blame others.
Posted Mar 16, 2024 0:40 UTC (Sat)
by Wol (subscriber, #4433)
[Link] (10 responses)
NO, NO AND THRICE NO!
The developer is victim (a *real* victim) for having the temerity to disagree with his users about what HE wants HIS code to do.
It comes over quite clearly that those users you are defending didn't give a shit about what the developer was trying to achieve.
The developer wanted the code to be FAST. The users placed safety over speed. That's their right, but it doesn't give them the right to steal someone else's project. As others have said, they have the right to *fork*, not *steal*. You have no right to tell me my priorities for my code are wrong.
Cheers,
Posted Mar 16, 2024 1:02 UTC (Sat)
by khim (subscriber, #9252)
[Link]
Don't publish it, if you don't want it to be looked on. Problem solved. Once again: it wasn't stolen. Kim had enough integrity to leave without making life of everyone who just uses Actix-web miserable. Kudos for him. That's more than authors of many other projects do when the majority of their users and/or codevelopers disagree with some decision: usually original project just dies and fork continues. Think XFree86 or OpenOffice.org. This doesn't make anyone happy, just makes everyone confused. What about Oracle? Is Oracle a victim of unfriendly community which doesn't want, for some reason, to donate their code on terms that Oracle would like, too? I don't like Kim for the games he played (and still plays) for the sake of benchmarks, but I appreciate his willingness not to involve innocents into these discussion (David Dawes-style). It was his decisions whether to continue (and try to cope with stigma, somehow) or quit. How can that be called “stolen project”?
Posted Mar 16, 2024 9:43 UTC (Sat)
by mb (subscriber, #50428)
[Link] (8 responses)
I doubt it. Very much.
>about what HE wants HIS code to do.
He can do whatever he wants to his code in private.
Posted Mar 16, 2024 10:49 UTC (Sat)
by khim (subscriber, #9252)
[Link] (4 responses)
Yes. It's about 30% slower on benchmarks. How much of it is real and how much is Dieselgate-style improvements is hard to say, but the majority of the Rust community vote went to safety and not to 30% speed increase. Simply because most of the time it's better to spend 30% more on hardware then lose millions from outages. Yup. That's precisely what happened here: Kim got his One may argue that “it's not fair” that community got the name, too, but we know from the history that it wouldn't have mattered in the long run anyway. Think gcc/egcs split, think LibreOffice/Apache OpenOffice, etc. The only thing that stubbornness of the developer brings in cases like that is damage for the innocent bystanders. The fact that Kim got enough dignity to accept that is a big plus for his human character IMNSHO, but that still doesn't mean I would like to use ntex instead of actix-web, sorry.
Posted Mar 16, 2024 11:08 UTC (Sat)
by mb (subscriber, #50428)
[Link] (3 responses)
And before the removal of the unsafe code it was this much faster? It was on top of the list?
Posted Mar 16, 2024 11:36 UTC (Sat)
by khim (subscriber, #9252)
[Link] (2 responses)
Yes. It was near the top, often #1. And that was, apparently, primary concern of it's author, his goal and achievment. And it's not as if “bullying” started from nothing. Read this article, e.g. Does it look like a bullying? Just read the whole discussion linked from there. Does this “car shouldn't have a seatbelts coz good drivers don't have accidents” or “bike helmets are for sissies, I wouldn't look cool if I would wear them” sound like a something you would want in an important project or library? The problem was always not the number of What you have if you program like that is not Rust, that's C++ in the Rust skin! That was the issue, not number of And when Kim started adding safe functions which exported unsafe behavior to bring down number of AFAICS Rust community dealt with it in the only way that actually works: try to educate, but if that doesn't work then expell. C/C++ community is full of such persons and it doesn't look as if any “safety plan” for C++ even acknowledges their existence.
Posted Mar 16, 2024 11:58 UTC (Sat)
by mb (subscriber, #50428)
[Link] (1 responses)
Ok, that is quite unusual then.
>The problem was always not the number of unsafe in Actix-web but the attitude that removal of unsafe needs a justification
Yes, I agree adding unsafe needs a justification. Not the removal.
Unsafe code is Ok, if it is carefully documented and thought through. The safe API to it must always be sound. Most of the time that means the unsafe code is down somewhere inside of a safe wrapper. But of course, that's not always easy to do and requires some serious engineering.
Posted Mar 16, 2024 12:26 UTC (Sat)
by khim (subscriber, #9252)
[Link]
The issue it that at certain point you reach the state where you have to make a choice. You may achieve, typically, about 50% of theoretical maximum performance while keeping architecture “safe and fast” bit at some point you hit the limit of what can be done that way. Axum is developed independently and it's very close to Actix-web on benchmarks (currently 5% fater, but that changes over time, it was 5% slower year ago). Beyond certain point you have to either do some hard choices or accept significant (though rarely critical) performance loss. Things like the decision of Windows NT 4.0 to move graphics drivers into the “microkernel”.
Posted Mar 18, 2024 14:42 UTC (Mon)
by pizza (subscriber, #46)
[Link] (2 responses)
Incorrect; the fact that this code is explicitly conformant with the language shows that Rust does indeed work this way.
If the programmer wants to do something "unsafe" to gain some speed (or any other reason!) then they are free to do so. It is, after all, their own code.
....congratulations, Rust is finally beginning to have to grow up and face the harsh fact that in the real world, developers will write crappy [1] code that violates any number of "cultural norms" or "best practices" [2] and there is *nothing* that can be done about it!
Rust-the-project has no legal (or moral!) ability to ostracize or otherwise exclude anyone from writing software in Rust, putting it online with a warranty disclaimer, and random third parties incorporating/using it. After all, that's how Rust itself continues to exist. Indeed, any exclusionary actions will likely lead to some expensive legal trouble.
[1] in the eye of the beholder
Posted Mar 18, 2024 15:02 UTC (Mon)
by khim (subscriber, #9252)
[Link]
Except the whole discussion started with example which directly contradicts your assertion. Yes, developers will write crappy code, but that's not a problem by itself. It only becomes a problem when crappy code becomes popular and is starting to affect other people while developer ignores the issue. And that can be fixed. It was done pretty successfully, or else we wouldn't have had this discussion at all. Seriously? When was Kim reinstated as the lead of Actix-web and his opponents were sent to jail? Indeed. But that doesn't mean that “nothing can be done”, as you assert. People are people, they find a way to achieve their goals. And if simple and obvious way doesn't work they find a roundabout way.
Posted Mar 18, 2024 15:10 UTC (Mon)
by Wol (subscriber, #4433)
[Link]
And the assumption that "users of Rust" are "members of the Rust community" is tenuous, in itself ...
> [2] The parallels here with TFA's "voluntary practices to improve safety in C++" are richly ironic
The important thing with Rust - and what the REAL Rust community presumably say - is that you cannot write unsafe code BY ACCIDENT.
Either (a) you have to wrap your own code in "unsafe" markers, or (b) you should KNOW whether or not you trust other peoples' code you're importing. Assuming the library author isn't lying (and in general, why should they) then you should KNOW whether their code contains unsafe blocks, and more importantly WHY.
After all, if it's acceptable to call out to C/C++, surely a bit of unsafe Rust is a drop in the ocean :-)
Cheers,
Posted Mar 17, 2024 17:10 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (2 responses)
Yes, and if the maintainer is "responsible" enough then the only, extremely well tested fix is to fork.
> It does not matter, if it's for free or not.
It very much does: most countries have laws that apply to business transactions. They obviously don't apply to random software you download from the Internet.
> If he doesn't want to be criticized for his work or can't handle it, he should not publish it.
Criticism is fine. Ignoring valid criticism is bad but it's perfectly legal. Repeating criticism that is legally ignored is called harassment. It's illegal in many places.
Posted Mar 17, 2024 17:14 UTC (Sun)
by mb (subscriber, #50428)
[Link]
Wow. I'm speechless.
Posted Mar 17, 2024 18:32 UTC (Sun)
by marcH (subscriber, #57642)
[Link]
I forgot: there's also a quote about doing the same thing over and over again and expecting different results.
Posted Mar 15, 2024 18:39 UTC (Fri)
by bartoc (guest, #124262)
[Link] (1 responses)
Rust doesn't even limit what you can express, you're welcome to wrap your whole program in unsafe {} and call it a day. Notably code that's inside an unsafe doesn't become less safe just because of the unsafe.
Indeed individual maintainers do need to enforce this stuff when accepting code, but that's always true.
I don't think anyone is going around inserting security bugs because they think it's fun.... I wager most serious memory bugs are introduced as a result of code changing over time, and I think this is where the lifetime system shines, since it allows you to introduce compilation errors into user code in much more precise ways when things change.
Posted Mar 15, 2024 22:36 UTC (Fri)
by khim (subscriber, #9252)
[Link]
We are not talking about “people who write memory errors”, but more like “people who use seat belt alarm silencer to drive without seat belt”. How do you call these people? Or people who are driving drunk? Or the guys who just ignore driving rules? They may be pretty amiable and even likeable guys… but they are danger for themselves and others!
> Rust doesn't even limit what you can express, you're welcome to wrap your whole program in unsafe {} and call it a day.
That's precisely why we need humans to take the slack when compiler couldn't do that. Sure, but like I wouldn't trust the guy who silences his seatbelt alarm with silencer not to do other reckless things… similarly I wouldn't trust developer who would use Except it doesn't work if you disable it. What do you with a guy which transmutes `&self` into `&mut self`? Or who reduces all-important number of Sorry, but to me it's pretty good example of an attitude which I don't want to see in projects I'm using. And calling that abuse is not slander IMNSHO.
Posted Mar 14, 2024 14:31 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
As Herb mentions "subset of a superset" is language dating back to at least 2014. What makes you think it's different this time? If (when) you're wrong, what's the insurance plan -- if we've committed to this safe C++ and it's actually a mirage, what delivers the safety we thought we were getting ?
"Safety profiles" is a vague ambition, if it's somehow uncontroversial (as if) and it's in good shape this year, you could see it in C++ 26, and you might own a conforming C++ 26 compiler in 2028. Or, I suggest, you could spend the intervening _four years_ weaning yourself off C++ and then regardless of whether the stars align and you get this feature, you're safer even if oops, "Safety profiles" is pushed back into C++ 32 or beyond.
Posted Mar 13, 2024 7:38 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (3 responses)
> What else can be done if developers are not even willing to to follow the rules of the language that they are using?
Simple, push-button automated enforcement. This can work only if you a have linter/sanitizer/analyzer simple to use that tells you if some piece of code is compliant or not.
This is not specific to C++, not specific to memory safety and not even specific to C++ developers. It does not matter whether it's a compilation error, warning, or some other static analysis, or even some code style rule: if you want something, then you need some automated way to enforce it and that's it. Otherwise you won't get it. Life really is that simple: you can only trust machines to consistently enforce tedious stuff, not humans. Humans are here to creatively solve problems, not to cross Ts and dot Is. They just suck too much at it - in any language.
Same thing with bugs: if you want code to support some use case, then you need automated test coverage for it. Otherwise it does not work.
Posted Mar 13, 2024 9:41 UTC (Wed)
by khim (subscriber, #9252)
[Link] (2 responses)
Doesn't work, sorry. That's not even something worth discussing, it's just a [relatively] simple mathematical fact. This may not work. Period. All these tools are fallible (by necessity, it's impossible to make them perfect) and may only work after developer already accepted the fact that it's developer, not tools, who is providing safety. Tools just help. Nope. Machines may find accidental violations. They are very good at that. But they couldn't enforce anything. That's still step one. Step zero is: ensure that all developers want to support that use case. And no, that's not a theoretical issue: I have seen it many times when people installed elaborated schemes of verifications with bazillion tests… and then outsorced important components. And then tests stop working. It's just very simple application of Goodhart's law. Dieselgate is the most famous example, but the same story is repeated again and again: if you say that passing tests is the goal, then people would write code that is passing the test, but doesn't actually work. And it's [almost] always possible. Tests protect against accidents, not against conscious action.
Posted Mar 13, 2024 16:38 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (1 responses)
Yes of course they're not perfect, you need an "escape hatch" like the "unsafe" keyword in Rust, "shellcheck disable=" , etc. But they get most of the work done which no human can do.
> and may only work after developer already accepted the fact that it's developer, not tools, who is providing safety.
The only way developers "accept facts" is when the boss says: these tests must pass. If they don't like it then they look for another job/project.
> Tools just help.
Nothing happens _consistently_ without automated "help"; otherwise failures will always fall through the cracks of good intentions and code reviews and with memory safety a single failure is enough. That's exactly what Stroustrup and Sutter are trying to fix right now with more rules and the _automated_ checks to enforce them. Without enforcement, any new rule is just "pretty please write modern C++" hand waving.
> It's just very simple application of Goodhart's law. Dieselgate is the most famous example, but the same story is repeated again and again: if you say that passing tests is the goal, then people would write code that is passing the test, but doesn't actually work.
Now that's why you _also_ need management and code reviews: to catch developers abusing "unsafe" and similar keywords and fire them and to constantly monitor and adjust the rules to avoid Goodhart effects. Of course you still need humans to supervise the machines; you can't just let them run unsupervised, sorry if I gave that wrong impression. You're right that automated tests are not enough; but they are required as the very first step because humans and code reviews are unpredictable and unscalable.
In the "Dieselgate", management _supported_ and _concealed_ the cheaters so it's a pretty bad example. No system can survive mass, deliberate fraud, that's pretty obvious.
Posted Mar 14, 2024 23:22 UTC (Thu)
by khim (subscriber, #9252)
[Link]
Why is it bad example? Where would you put people like Victor Yodaiken who still, even today, boldly proclaim that that it's Ok to write code with UB and compilers should just magically stop breaking such code? Many of them are developer with years of experience, they are considered experts and management supports them because they deliver. Just like developers of Volkswagen delivered what they were supposed to deliver. It maybe pretty obvious for you but it's not obvious to “we code for the hardware” crowd. They believe they have the right to massively lie to the compiler, deceive it and then still expect predictable output from it. They are far from being rare and unique and none of these proposals address their existence even if without addressing that social issue all technological marvels wouldn't help you.
Posted Mar 13, 2024 7:20 UTC (Wed)
by b7j0c (guest, #27559)
[Link] (4 responses)
Posted Mar 13, 2024 20:56 UTC (Wed)
by marcH (subscriber, #57642)
[Link] (3 responses)
What is being discussed is effectively a fork/"choice" between unsafe C++ and safer C++. You don't need everyone to be on board to fork. You don't even need the majority to be on board. You don't need to rewrite all unsafe C++ overnight either.
The "only" thing you need is a small number of very good C++ experts to:
It's not a small task at all and I wouldn't bet on it but the fact that there is a lot of C++ out there is not a blocker.
Being "as safe" as Rust is not an absolute requirement either - I think that's the main point of this blog.
Defining "safer C++" is not so different from defining C++17 or C++20. These sometimes deprecate and/or remove features too and they sometimes break existing code too. Granted, "Safer C++" needs to break a lot more legacy code: it's quantitatively different but not qualitatively different.
Posted Mar 13, 2024 21:05 UTC (Wed)
by mb (subscriber, #50428)
[Link]
Aaaaaand this is where the whole approach falls apart.
Posted Mar 13, 2024 22:02 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Or you copy yet another trick from the Rust toolbox. The *default* is "safe C/C++", but you flick the C99/C++25/whatever switch, and all your old, dodgy code will still compile, run and fall over just as before.
Cheers,
Posted Mar 14, 2024 23:26 UTC (Thu)
by khim (subscriber, #9252)
[Link]
C++ couldn't pull that trick. At least not just yet. You need to first stop using C++20 added proper modules, but their adoption is still not something to write home about.
Posted Mar 12, 2024 20:00 UTC (Tue)
by ebee_matteo (subscriber, #165284)
[Link] (2 responses)
Look at the problems inherent in the C++ module system. The lack of proper packaging. No test framework integrated with the language. Clunky header+implementation file separation with inconsistent marking of attributes. UTF-8 strings without built-in UTF-8 support. It took 30 years to get imperfect timezone handling...
It's unfixable. It's far too complex. The only *good* thing would be *breaking backwards compatibility* and only say "use this subset".
It does its job for the person who can spend 10 years learning it. It sucks for somebody who wants to get their stuff done and go home.
Using C++ if you are a violinist like Paganini is great. Most people play it like a first year student.
So I think it has its place and it will stay. I myself have 18 years of C++ experience, of which more than 10 professional experience. And yet, if I can avoid it because I don't need to squeeze out the last 30 milliseconds performance, I will turn to something else (typically Rust).
It's good when you need those last 30 milliseconds. Terrible otherwise.
Posted Mar 14, 2024 10:23 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (1 responses)
It does its job for the person who can spend 10 years learning it. It sucks for somebody who wants to get their stuff done and go home.
Using C++ if you are a violinist like Paganini is great. Most people play it like a first year student.
With that context in mind, it's worth noting that the people trying to fix C++ are people who've spent at least 20 years mastering the language, if not more. These are the "violinists like Paganini" of the C++ world.
And it's not surprising, in this context, that they're trying to avoid a world in which C++ gradually fades the way COBOL has; it's not dead and buried like PL/I, but it's becoming less and less relevant over time. Worse, for C++ expertise, Rust is getting good at squeezing out as much performance as C++ can, if not more (because it doesn't have to care about compatibility with C++98 source code in the standard library), and there's a real risk that in the not too distant future, for every niche C++ currently sits in, Rust (with targeted use of unsafe) will be a better choice than C++ assuming you have no legacy code.
And while COBOL isn't a bad skill to have (there's well-paid jobs, for a start), just knowing COBOL and nothing else removes you from "exciting new" code, leaving you on "maintain legacy only", with other languages used for "exciting new" code. Pushing C++ into that bucket is not what people whose careers are built on using C++ for "exciting new" code want to see happen.
Posted Mar 14, 2024 23:12 UTC (Thu)
by khim (subscriber, #9252)
[Link]
I think that's already the case: if you don't have legacy C++ codebase which you couldn't rewrite then using Rust is the best choice 10 times out of 10. But if you do have such a codebase then this “subset of a superset” approach wouldn't work either! > If they would have started talking about that 10 years ago (that's year 2014, before Rust hit 1.0 milestone, before it's stability declaration arrived and before it was tested by time) then chances are very high that Rust adoption would have been slowed down significantly and people would have patiently waited for promised “safety profiles” and everything. Today… they are already developing schemes which would allow them to escape (things like crubit) and when promised “subset of a superset” would actually materialize one attempt or another would reach the usable state.
Posted Mar 12, 2024 20:18 UTC (Tue)
by TristonC (guest, #165547)
[Link]
Posted Mar 12, 2024 21:33 UTC (Tue)
by bredelings (subscriber, #53082)
[Link] (8 responses)
I have been skeptical about the claim that most bugs are memory bugs. Memory bugs definitely make everything trickier, but I still think that most bugs are logic bugs.
Posted Mar 12, 2024 22:31 UTC (Tue)
by khim (subscriber, #9252)
[Link]
That's because said claim is just not true at all. It's clarified in the very next sentence in the article: e.g., using Rc, or using integer indexes as ersatz pointers. In addition to use of Rc you may use arenas, graphs, self-referential structs and more. Yes, all these crates employ
Literally every time I saw and wrote complicated pointer manipulations with unclear non-tree structure interspersed with “business logic” in C/C++ (in my code and otherwise) the end results were long debugging sessions and tears of frustration. And if you implement such complicated data structures in separate modules anyway difference between C/C++ and Rust suddenly become much smaller than simple statement from the article may imply.
Posted Mar 13, 2024 12:16 UTC (Wed)
by dvrabel (subscriber, #9500)
[Link] (6 responses)
Posted Mar 13, 2024 15:16 UTC (Wed)
by yodermk (subscriber, #3803)
[Link] (5 responses)
Posted Mar 13, 2024 17:26 UTC (Wed)
by mb (subscriber, #50428)
[Link]
Posted Mar 14, 2024 1:04 UTC (Thu)
by dvrabel (subscriber, #9500)
[Link] (3 responses)
Arc::into_inner() may or may not get the inner value. If the program is expect()'ing to get the inner value but doesn't because some other part of the program is holding a reference it shouldn't, the program will behave incorrectly.
You can create cycles with Arc which whilst safe are not always correct (because the inner objects can be leaked).
Posted Mar 14, 2024 1:39 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link] (2 responses)
This is an unreasonable expectation. Arc::into_inner() is a highly specialized interface. It is not designed for general use. It *should* be hard to use correctly.
Before I explain how this interface should be used, we need to take a step back and talk about the actual problem that it is trying to solve. You have an object behind an Arc; let's say it's Arc<Foo> (for some type Foo). There are several different reasons you might plausibly want to use this function:
* You want to mutate the Foo instance. Then call Arc::get_mut().
All of the above are straightforward to use correctly and have no problems with silently doing the wrong thing. Here is the actual use case for Arc::into_inner():
* You want to take the Foo object out of the Arc and consume it, you don't want to do that until it is no longer in use, you don't want to write code for the case where the Foo has already been consumed, the code that consumes the Foo can't feasibly live in Drop::drop(), *and* you know that all clones of the Arc are owned by worker objects or worker threads, which all know how to consume the Foo at the end. Then all you have to do is ensure that every function which takes an owned Arc<Foo> either consumes it with into_inner() or passes it along to another part of the worker logic, and that it is never permanently stored in some long-lived data structure. And yes, that is difficult, but as mentioned, all of the simple use cases already have another solution which is easier to use and just as performant (or nearly so).
Posted Mar 14, 2024 10:12 UTC (Thu)
by dvrabel (subscriber, #9500)
[Link] (1 responses)
If I have a T I can get a &mut T only if the compiler can prove that it is safe to do so.
If I have a Arc<T> I can only get a &mut T if the runtime check of the reference count says it is safe.
Posted Mar 14, 2024 16:59 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
Posted Mar 12, 2024 21:42 UTC (Tue)
by itsmycpu (guest, #139639)
[Link] (18 responses)
The frequent use of tools like address sanitizer and thread sanitizer seems a necessity for a larger codebase. I'm surprised that enabling a large number of warnings (and fixing them all), and the use of asserts for checking null pointers in parameters and elsewhere, are not on the list (with two assert macros: one that also executes in release mode, and one that executes only in debug mode, and additional checks that are compiled conditionally.) Maybe too obvious? I think static analyzers could be even better and thorough, but it is important that they don't have non-fixable false positives, meaning that it needs to be easy enough to avoid or silence false positives without turning the warnings off completely. (Lately I had cases where that seemed almost impossible, perhaps issues in a new compiler version. It seemed a bit like the compiler engineers may have had insufficient appreciation for the harm done by false positives.)
Posted Mar 12, 2024 22:36 UTC (Tue)
by khim (subscriber, #9252)
[Link] (7 responses)
I recommend you to actually take a look on these Rust CVE's. The first one is absolutely perfect: When receiving compressed HTTP payloads, affected versions of the Router evaluate the Yes, technically it's a bug, but how many C/C++ developers do you know that would accept that as an actual vulnerability?
Posted Mar 13, 2024 7:11 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link] (6 responses)
Do it from a few clients and and you got your memory full :)
Who wouldn't consider this a vulnerability?
Posted Mar 13, 2024 9:51 UTC (Wed)
by khim (subscriber, #9252)
[Link] (4 responses)
And then your process is killed and restarted. That's DoS attack, not a vulnerability. Most developers, I suspect. If the worst outcome is “your service doesn't respond because it's clogged with requests” then usually it's achievable without any vulnerability and said bug doesn't give you the ability to do more than that. P.S. Actually I suspect under new rule kernel guys would give it a CVE because their goal is to ensure that no vulnerabilities would be unmarked, not to paint the whole world into black and write colors for the PHB to be happy, somehow. Compared to CVE-2023-52472 this is, indeed, serious vulnerability. But before CVE process was exposes as meaningless farce only Rust guys cared about stuff like that.
Posted Mar 13, 2024 10:55 UTC (Wed)
by cmeerw (guest, #555)
[Link] (2 responses)
Posted Mar 13, 2024 11:06 UTC (Wed)
by khim (subscriber, #9252)
[Link] (1 responses)
Well… that's year 2003. Maybe in year 2045 Rust, too, would devolve to the state where we would need another new language for safety.
Posted Mar 13, 2024 11:15 UTC (Wed)
by cmeerw (guest, #555)
[Link]
Yes, that's year 2003. Not sure what you are trying to say. You were earlier claiming "only Rust guys cared about stuff like that" and "how many C/C++ developers do you know that would accept that as an actual vulnerability". Looks like people care about stuff like that since at least 2003 - and there was quite a bit of publicity about that around that time. It even has it's own Wikipedia entry.
Posted Mar 13, 2024 11:19 UTC (Wed)
by LtWorf (subscriber, #124958)
[Link]
From the other comments I think that you are not using rationality when talking about rust.
A full memory might easily mean degraded performances and swap, rather than a service being restarted (hoping that the OOMkiller picks the right process).
Posted Mar 13, 2024 21:40 UTC (Wed)
by dvdeug (guest, #10998)
[Link]
Posted Mar 13, 2024 19:41 UTC (Wed)
by mb (subscriber, #50428)
[Link]
But that is actually misinterpreting the numbers.
In Rust it takes *two* things to have a memory safety vulnerability:
1) An unsound use of unsafe Rust code somewhere in an abstraction or directly.
Rust CVEs are usually done if 1) is violated. But that usually does *not* mean that there is an actual vulnerability. Just the possibility for somebody to use the unsound code in a vulnerable way.
Example:
Of course it is possible that unsound code immediately is also vulnerable. But that's rarely the case in practice.
So you get programs marked with a CVE because of 1) only.
It's a completely different mindset. The biggest difference between C++ and Rust is not the language, but the mindset of the people using it.
Posted Mar 14, 2024 9:55 UTC (Thu)
by ianmcc (subscriber, #88379)
[Link] (8 responses)
Posted Mar 14, 2024 13:28 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (4 responses)
I think the fact you were able to look at the C++ vulnerabilities reported in most of 2023 and decide they can't "definitely be attributed to C++" reminds us that the only value CVEs were definitively intended to deliver was to allow us to agree about which vulnerability we're talking about. We don't know what the bug really is, which language the code was written in, or really anything but we've got an ID for it so that's something.
Posted Mar 14, 2024 16:23 UTC (Thu)
by ianmcc (subscriber, #88379)
[Link] (3 responses)
Posted Mar 15, 2024 0:11 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link] (2 responses)
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c++
The URL you'd obviously actually write to search for the text C++ is:
https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=c%2B%2B
I further assumed you were talking about the actual C++ CVEs reported in the last year, rather than that you'd taken Herb's word for it and assumed whatever nonsense he found by searching for the letter C is the C++ vulnerabilities. It's definitely possible (if you're a C++ proponent) to insist that all the bugs in C++ just aren't really C++, just as a "True" Scotsman would never use sugar on porridge.
But yeah, sure, if you follow Herb's link you're mostly looking at the spew of Linux kernel CVEs and you learn nothing.
Posted Mar 15, 2024 1:48 UTC (Fri)
by tialaramex (subscriber, #21167)
[Link]
This is asking GitHub to match CWE-787 (bounds miss write) against 2024 CVEs. Obviously not all of these will be C++ either, but it should be much less noisy than Herb's "Every CVE with the letter C in it" link, and of course "bounds misses" are exactly one of the things the Memory Safe Languages defend against.
Posted Mar 15, 2024 14:31 UTC (Fri)
by ianmcc (subscriber, #88379)
[Link]
Posted Mar 14, 2024 19:49 UTC (Thu)
by roc (subscriber, #30627)
[Link] (1 responses)
Posted Mar 14, 2024 19:53 UTC (Thu)
by roc (subscriber, #30627)
[Link]
Posted Mar 14, 2024 20:01 UTC (Thu)
by draco (subscriber, #1792)
[Link]
One year, there were more "rust" CVEs than "C++" ones by 2:1, and I just don't find that remotely credible. Mind you, my processing of the data was extremely sloppy (counting every hit of a token that matched the CVE ID pattern in each HTML page, removing duplicates and collating by year).
But implementation language isn't a field in the CVE records, so I think this is all just noise. Getting usable data for this question would require a fair amount of research, and even then, commercial software doesn't tend to talk about implementation language, so you're going to have gaps/skews in the data.
Anyway, I doubt that's what ultimately swayed him to concede that C/C++ has a problem. I think he was really using this data to say that C++ doesn't need to eliminate 100% of memory safety issues to be "good enough," which is an interesting statement since I don't think anyone informed is even claiming that.
The whole response is an interesting mix of "giving context" and concession.
Posted Mar 12, 2024 23:26 UTC (Tue)
by pctammela (guest, #126687)
[Link] (22 responses)
Posted Mar 13, 2024 3:49 UTC (Wed)
by atai (subscriber, #10977)
[Link] (21 responses)
Posted Mar 13, 2024 11:53 UTC (Wed)
by pctammela (guest, #126687)
[Link] (20 responses)
Posted Mar 13, 2024 17:27 UTC (Wed)
by atai (subscriber, #10977)
[Link] (19 responses)
Posted Mar 14, 2024 1:12 UTC (Thu)
by pctammela (guest, #126687)
[Link] (3 responses)
Posted Mar 14, 2024 21:59 UTC (Thu)
by pawel44 (guest, #162008)
[Link]
Being capable doesn't mean it's a good replacement.
Posted Mar 15, 2024 18:44 UTC (Fri)
by bartoc (guest, #124262)
[Link] (1 responses)
Much of Rust's UB corresponds exactly to LLVM UB, and C++ has more UB than just that, and sometimes implementations end up providing consistent behavior for some UB without going through the standards process (just by happenstance, and vendors have incentives not to differ from other implementations for "no reason"). C makes this even more obvious.
Posted Mar 15, 2024 23:01 UTC (Fri)
by khim (subscriber, #9252)
[Link]
Not precisely. Some UBs were ingrained pretty deeply into LLVM and required patches to handle them. One example is “forward progress” UB was ingrained into LLVM pretty deeply and it took a lot of effort to make it non-UB. But it was critical for the ability to claim that normal, safe, Rust couldn't generate UB (at least not easy, without [ab]using soundness bugs in the compiler), so that was done. We are way past the point where that was true. Just look on this [recent] gem. Someone have added this nice “optimization” which is pretty much [ab]uses UB to break code which it's author have always considered valid. Is “we have saved 0.1% on some benchmark at the cost of putting few new mines on the well-trodden road” good enough justification? But if C/C++ couldn't even accept any changed that would just make already existing code safer then what hope is there that these “security profiles” would be adopted by anyone?
Posted Mar 14, 2024 1:27 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
C++ has quite a schizophrenia. For example, the C++ standard relies heavily on exceptions, the STL is not feasible without them. Yet half of the current large C++ users prohibit exceptions.
Posted Mar 14, 2024 9:40 UTC (Thu)
by taladar (subscriber, #68407)
[Link]
Posted Mar 14, 2024 10:42 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (12 responses)
But for C++ 98 we can say that this isn't a coherent design. The jump out incoherence is the provision of "I/O streams" a pet project of Bjarne Stroustrup - contrasting against an admonition that overloads of the C++ operators should reflect the operator's usual meaning and not invent new meanings. Does std::cout << count << " things were counted.\n"; really reflect the usual meaning of a shift operator?
Bjarne's excuse is to declare that actually this isn't a shift operator, it's a different operator which just happens to have identical spelling and identical precedence (even though that makes no sense). The response ought to be uproarious laughter, but instead this seems to have been taken quite seriously.
But OK, maybe we'll give I/O streams a pass, what about the general operator overloading scheme. The short circuiting boolean operators && and || can be overloaded in C++. What happens to our short circuiting for this scenario? We might expect some pretty fancy footwork is needed to deliver a way to overload the operator and yet provide short circuiting behaviour - nope C++ just doesn't offer short circuiting for the overloaded operator, too bad.
You compare against C, but C doesn't have these coherency problems. So in these respects C++ is not better it's worse
Posted Mar 14, 2024 11:42 UTC (Thu)
by ianmcc (subscriber, #88379)
[Link] (11 responses)
Overloading && and || isn't very common, the only times I can recall seeing it is in dubious attempts at a DSEL where short-circuit evaluation doesn't make sense anyway. Do you have a use case for overloaded && or || where you also want short-circuit evaluation?
Posted Mar 14, 2024 19:59 UTC (Thu)
by roc (subscriber, #30627)
[Link] (10 responses)
Posted Mar 14, 2024 23:38 UTC (Thu)
by khim (subscriber, #9252)
[Link] (9 responses)
Is Rust any different? How many Rust developers don't know nuianced things like how Probably as many as C++ users who have no idea what template template parameter is and whether you can pass template function via such parameter. Both languages are way too large and complex for an average developer to know all the nuances.
Posted Mar 15, 2024 0:21 UTC (Fri)
by roc (subscriber, #30627)
[Link] (2 responses)
The Rust code I wrote 8 years ago is still, as far as I know, reasonably idiomatic today. Maybe there are some uses of the try! macro that should be ?, but that's trivial.
Posted Mar 15, 2024 10:10 UTC (Fri)
by khim (subscriber, #9252)
[Link] (1 responses)
Rust still is relatively young and unfinished. For the first 13 years of it's existence C++ was relatively stable, too. Only auto_ptr was first deprecated, then removed and replaced with unique_ptr. But eventually it was realized that you couldn't efficiently bolt-on movable types into C. You need to redesign the whole language. Rust is repeating this same story with I wouldn't be surprised to find out that in year 2030 it would be realized that we couldn't integrate these things into Rust and a new language is needed. Then around year 2040 said new language would finally materialize. Would Rust developers act like C++ users today? Only time will tell.
Posted Mar 15, 2024 20:54 UTC (Fri)
by roc (subscriber, #30627)
[Link]
Posted Mar 15, 2024 9:22 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (5 responses)
This isn't the same as "doesn't know the nuance". This is the equivalent of Rust saying "println!, eprintln! and the Debug and Display traits have been removed. You will need to manually replace them to update your code, and there is no automatic fixer".
Posted Mar 15, 2024 11:43 UTC (Fri)
by ianmcc (subscriber, #88379)
[Link] (4 responses)
Posted Mar 15, 2024 12:08 UTC (Fri)
by farnz (subscriber, #17727)
[Link] (2 responses)
And therein lies the problem for any "safety" improvements in C++; if you merely deprecate the parts that aren't memory-safe, and allow them to coexist, people will stick with their old habits. If you remove them, then existing C++ breaks, and breaks badly, requiring people to relearn the language.
This is the challenge for any language trying to make a change that involves removing existing features that people make use of; do you remove those features and break existing users in the hope of attracting new ones, or do you leave them in place and risk people ignoring the change you want to make? Note that for memory-safety, not removing the features people use that are unsafe means that I can compile with any profile set and code that's not memory-safe will continue to compile without a diagnostic like it does today - and that's a big challenge that no language I'm aware of has an answer to (even Rust's editions don't fully answer this problem).
Posted Mar 15, 2024 16:59 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (1 responses)
Pain in the arse, but for anybody who is serious enough to switch on a safety profile, they should be prepared to deal with the fallout. As I've said before, when I inherited a dodgy codebase, I just slowly ratcheted up the warning level, fixing things as they came up, until it got rid of most of the bugs without me ever actually finding half of them ... :-)
Cheers,
Posted Mar 15, 2024 18:50 UTC (Fri)
by farnz (subscriber, #17727)
[Link]
But the moment you start issuing a diagnostic for C++ features that the profile bans, you've reduced the value of the profile significantly; if you were willing to rewrite the codebase to fix the issues, the cost savings of "rewrite in C++ with safety profile, use a C++ without safety profile compiler for the bits that aren't yet fixed" aren't significant compared to "rewrite in Rust, use cxx.rs to allow you to keep reusing all the C++ code that's not yet rewritten".
If the "safety profile" idea had reached usable status before Rust reached 1.0, then it would have a decent chance; but it's competing against a social reality where the people most willing to change the way they work have moved to Rust over the last 8 and a bit years, and the longer it takes to arrive, the fewer people will be left willing to learn a new language called "C++ with safety profile" but not a new language called "Rust".
Posted Mar 15, 2024 21:07 UTC (Fri)
by roc (subscriber, #30627)
[Link]
Herb Sutter's plans would add safety rules to that list.
I'm not saying it's overall bad to evolve the language in this way. It's probably overall good. But when you make these changes you need to be honest and admit that to some extent, you've forked the language and developer community.
Posted Mar 13, 2024 7:41 UTC (Wed)
by cyperpunks (subscriber, #39406)
[Link]
The move to memory safe programming language is such paradigm shift.
Posted Mar 13, 2024 13:15 UTC (Wed)
by CChittleborough (subscriber, #60775)
[Link]
Sutter does not really get into technical details until the Appendix of this article, and even there he mostly just links to profiles (ie., collections of guidelines) defined in the Guidelines. So IMO this article is an advocacy piece for the Guidelines. He's arguing that C++ can be made significantly better by adopting (some as-yet-undetermined subset of) those Guidelines, and his argument is pitched at C++ programmers and implementers who don't want those changes.
I think he's right. IMO, widespread adoption of (most of) those guidelines would (1) make C++ easier and safer to program in, and (2) provide a practical way to improve many existing C++ libraries and programs. Modern languages such as Rust, Go and Swift would still be much safer than C++, but C++ would be a lot less dangerous.
Posted Mar 13, 2024 17:25 UTC (Wed)
by proski (subscriber, #104)
[Link] (5 responses)
- My colleague: Your last commit broke the main branch.
My current job. We code in Rust. I get to the office in the morning.
- My colleague: Your last commit broke the main branch.
I'm not a Rust fanboy, but coding in Rust feels so different. Sometimes it takes a lot of work to persuade the compiler that my code is safe, but it's worth the peace of mind I have afterwards. I don't think C++ can catch up, especially if it keeps backwards compatibility. Maybe C++ experts should work on a C++ successor that looks like C+ but offers protections similar to those offered by Rust.
Posted Mar 13, 2024 17:41 UTC (Wed)
by atai (subscriber, #10977)
[Link] (4 responses)
Posted Mar 13, 2024 17:47 UTC (Wed)
by mb (subscriber, #50428)
[Link]
I totally agree that developing a Rust application feels _so_ much different to writing an application in any other language I have used so far.
Posted Mar 14, 2024 11:58 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link]
Of course there will be C++ jobs for the foreseeable future, it won't be a worthless skill to have, maybe in ten or fifteen years a C++ maintenance gig pays off your house or allows you to retire early while a Rust job wouldn't have matched that because the skills are more common by then. But I'd rather be paid barely enough and be happy at work than be rewarded handsomely for something that's awful. Today I don't write Rust _or_ C++ at work but if you told me tomorrow we'll be writing C++ I would probably resign and if you told me we'll be writing Rust I'd question why (doesn't seem applicable for the problems we have or else I'd suggest it myself) but I'd be happy.
Posted Mar 14, 2024 12:40 UTC (Thu)
by farnz (subscriber, #17727)
[Link] (1 responses)
I am old enough to remember people telling me that this "C" thing was a flash-in-the-pan, and your next job would be COBOL, because too much COBOL code needs to be maintained.
And that is still, in limited senses, true; if you are happy maintaining legacy code, and not working on new problems, then there's still decent jobs for COBOL programmers. But I don't see many (if any) new projects picking COBOL over any other implementation language; and I do see jobs replacing the last vestiges of a COBOL system with something new.
Posted Mar 16, 2024 15:09 UTC (Sat)
by hunger (subscriber, #36242)
[Link]
We will see how fast the industry can adopt a new language when the old language starts to effect the bottom line. It will effect the bottom line if regulations come in effect.
Posted Mar 14, 2024 2:20 UTC (Thu)
by roc (subscriber, #30627)
[Link]
One problem is that it's a bit of a bait and switch. He wants everyone to migrate to a subset of a superset of C++ ---- a pretty different language to what a lot of C++ users are used to --- but he also wants them to believe it's the same language that they already use and know. It really isn't.
Still I agree that if he could pull it off, it would have real advantages over Rust, like easier C++ interop.
Posted Mar 14, 2024 12:01 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (3 responses)
Possibly.
But with GCC aquiring the ability to build Rust, I can't help but foresee some 800lb brain making Rust's borrow checker at least an opt-in extension for C++, and maybe leading to enough fundamental language changes to enable it.
Look at the name: C++ is first and foremost a feature vamp.
Posted Mar 14, 2024 19:16 UTC (Thu)
by mb (subscriber, #50428)
[Link] (2 responses)
That is not really possible.
Posted Mar 14, 2024 20:01 UTC (Thu)
by roc (subscriber, #30627)
[Link]
Evolving C++ into Rust is a long and painful road but it might be worthwhile for some users.
Of course, if you can use Rust today and skip that road, you absolutely should.
Posted Mar 14, 2024 21:20 UTC (Thu)
by NYKevin (subscriber, #129325)
[Link]
* If you want to get rid of data races, then it's really hard to avoid mutable xor shared semantics (without doing something really crazy such as mandating pervasive memory barriers, atomics, and/or locking).
I'm not really a fan of the way that C++ has chosen to implement move, but it does happen to be mildly convenient here.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> I think given sufficient motivation and functional governance processes, it would be perfectly possible to get C++ to a better point.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> Just let me clarify this: you use a blog post by one of Rust's founders in which he _laments_ the intolerant and nasty response of the broader Rust community to certain technical issues with a certain project as a reason to _celebrate_ this kind of response and suggest that it is the _only_ right thing to do?
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
> I don't think your attitude is going to encourage many people to look positively at the rust community.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
[2] https://www.theregister.com/2020/01/21/rust_actix_web_fra...
[3] https://github.com/actix/actix-web/issues/1289
[4] https://www.techempower.com/benchmarks/#hw=ph&test=fo...
[5] https://github.com/fafhrd91
[6] https://ntex.rs/
[7] https://github.com/ntex-rs/ntex
> But I want to point out that "kicked out" is not, to my knowledge today, an accurate picture of how the Rust community responded to this situation, and I think that is all for the better.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> Again, how does it seem more accurate to use the ostracism metaphor rather than a fork?
Herb Sutter on increasing safety in C++
Phew, the exhausting indefatigability of this self-justification...
Phew, the exhausting indefatigability of this self-justification...
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Publish something and get feedback. That includes positive and negative feedback.
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
They "stole" and open source project. How? By making the original author step back? Oh pardon, by "expelling" him?
I guess many people then also stole my old projects that I don't maintain anymore and I stepped back from.
https://www.theregister.com/2020/01/21/rust_actix_web_fra...
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
Obsolete opinions die.
Herb Sutter on increasing safety in C++
Wol
> There's a big difference between taking over an abandoned project, and muscling in on a project that the creator is actively working on.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
I have *never* said that abuse and bullying is acceptable. Abuse and bullying is never acceptable, if course.
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
That all confirmed that he is not a victim but rather a very unprofessionally acting person, to say it mildly.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
The author is not the victim.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
https://github.com/actix/actix-web/pull/968
https://github.com/actix/actix-web/pull/822
https://github.com/actix/actix-web/pull/335 (note reverted after merged)
https://github.com/actix/actix-web/issues/289
https://github.com/actix/actix-web/pull/1303
https://github.com/actix/actix-web/pull/1328
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> That you and mb think that kind of behaviour is acceptable, indeed you appear to be _celebrating_ it, suggests the "Rust community" has learned _nothing_ from that episode - so far as your comments are representative.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> I feel like this sort of thing is an area where there is a huge disconnect between people actually involved with the rust project or any projects of note (like e.g. Steve Klabnik, who condemned this strongly in the blog post linked) and a certain genre of poster especially prevalent on places like reddit, where this kicked off.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Wol
This post suggests we're reaching (if not going beyond) the point where it might be a good idea to wind down this conversation. I don't think there's much more to be said that might change anybody's mind.
This might be a good stopping point
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
That's what he did.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> That's what he did.
The whole point of this thread is that apparently it was NOT his free choice. He was *driven* out.
Wol
Herb Sutter on increasing safety in C++
There is no loss for the maintainer to continue to maintain the project in private or as a separate minor project.
if the maintainer does not care about the users, it should be no problem to maintain a fork.
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
I do my best to avoid unsafe code, because it is risky for my users.
If a user comes and suggests to replace unsafe code with a equivalent safe alternative, I will be grateful. I will apply it.
If there is a vulnerability in my published code, I am responsible for doing my best to fix it ASAP or at least to clearly mark it as vulnerable ASAP if I don't have the time to fix it. Users depend on my work. Users trust me. That makes me responsible.
I do my best to reduce risk for my users.
If I would not care about my users, I would not publish my projects.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Therefore, that cannot be the reason for the step down.
He could have just continued with his "me driving in the right direction and 1000 people driving wrong".
And most important, don't complain, if all users tell you that you are wrong. Because most likely you are wrong.
Herb Sutter on increasing safety in C++
[2] Which can include "happy wife, happy life" euphamisms.
Herb Sutter on increasing safety in C++
I think the user might be right.
But that means that I will *have* to leave the project, if the majority of users wants a feature that I reject.
I can still maintain the project without this feature in private or as a fork.
I really don't see the problem.
I would not loose anything.
IMO that is pretty obvious.
But ya know. I might be wrong. Who knows.
Herb Sutter on increasing safety in C++
> I think the user might be right.
Wol
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
I think the user might be right.
Herb Sutter on increasing safety in C++
That has nothing to do with "hijacking".
And so were his responses in the PRs trying to improve that code. Please look at it.
The major part of free software is collaboration, communication and technical improvements. All three of which the maintainer failed at, in the opinion of many users.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
You see, the author complains about stuff that he does, too.
You are disagreeing with me and instead of going your way and forking this discussion to somewhere else, you keep on "harassing" me (by your definition) by trying to push your opinion onto me.
How rude. I am the victim. (Not really. It's called a discussion.)
It's a discussion that, I think, has run its useful course and beyond; perhaps we could bring it to a close, please?
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
So? That means users can't complain about unsafe code? The developer is a "victim" for defending his unsafe code?
If I feel unhappy about unsafe code in a project that I use, I will complain. That is my right. It is the right of the developer to not listen. If the developer takes it personally, that is the developer's decision. He's not a victim. He's just wrong, from my POV.
Herb Sutter on increasing safety in C++
> So? That means users can't complain about unsafe code? The developer is a "victim" for defending his unsafe code?
Wol
> You have no right to tell me my priorities for my code are wrong.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
In Rust you almost never trade safety for speed. That's not how Rust works.
If your point is right, the project must be much slower today.
Is it?
But if a developer publishes some code, the developer must be able to live with feedback.
And if a developer publishes code that goes against the fundamental rules of the ecosystem and receives the corresponding answers, then he's not a victim. He should either learn from the answers or step back from the project and continue it in private.
Be responsible for the things you do in public.
> If your point is right, the project must be much slower today.Herb Sutter on increasing safety in C++
Is it?
ntex to play benchmark games, community got something they may trust.Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
unsafe in Actix-web but the attitude that removal of unsafe needs a justification, while using them when pesky compiler complains is fine.unsafe words per see.unsafe code blocks… how do you deal with that?Herb Sutter on increasing safety in C++
I guess they took the other extreme and also removed all unsafe code that made sense? Or is the architecture so broken and it can't work safely and fast at the same time?
> Or is the architecture so broken and it can't work safely and fast at the same time?
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
[2] The parallels here with TFA's "voluntary practices to improve safety in C++" are richly ironic
> ....congratulations, Rust is finally beginning to have to grow up and face the harsh fact that in the real world, developers will write crappy [1] code that violates any number of "cultural norms" or "best practices" [2] and there is *nothing* that can be done about it!
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> Calling people who write memory errors abusers is .... a bit much.
Herb Sutter on increasing safety in C++
unsafe without any good reason or explanation.unsafe uses by providing safe wrappers which just call unsafe function without any checking? Is it still within “innocent guy who just happen to do some memory errors” boundary to you?Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> Simple, push-button automated enforcement.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> ...
> That's still step one. Step zero is: ensure that all developers want to support that use case.
> In the "Dieselgate", management _supported_ and _concealed_ the cheaters so it's a pretty bad example.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
- agree on what exactly "safer C++" should be
- implement the push-button tooling that can instantly tell you whether some piece of C++ is "safer" or not and why.
Herb Sutter on increasing safety in C++
>- agree on what exactly "safer C++" should be
Herb Sutter on increasing safety in C++
Wol
> Or you copy yet another trick from the Rust toolbox.
Herb Sutter on increasing safety in C++
#include as poor man replacement for modules first, otherwise it's pretty much impossible to say which code is supposed to be written in an “old version” and which should be written in a “new version”.Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
It's unfixable. It's far too complex. The only *good* thing would be *breaking backwards compatibility* and only say "use this subset".
> there's a real risk that in the not too distant future, for every niche C++ currently sits in, Rust (with targeted use of unsafe) will be a better choice than C++ assuming you have no legacy code.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> I haven't heard the claim about Rust only handling tree-like data structures in safe code before.
Herb Sutter on increasing safety in C++
unsafe inside but to just use them you don't need to go outside of safe Rust subset… and that how you have to design and use them in C/C++, too (if you value your sanity, at least).Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
* You want to dispose of something owned by the Foo when the refcount drops to zero. Then implement Drop for Foo, and write the code in its drop() method.
* You want to replace the Foo instance with a different Foo instance. Then call mem::replace() or mem::swap() on the &mut Foo that you can get out of get_mut().
* You want to do one of the above, even if another thread might be using the Foo instance. Then wrap the Foo in a sync::Mutex or sync::RwLock.
* You want to take the Foo object out of the Arc and consume it. Then use an Arc<Option<Foo>> (plus a lock, if desired) and call Option::take().
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
limits.http_max_request_bytes configuration option after the entirety of the compressed payload is decompressed. If affected versions of the Router receive highly compressed payloads, this could result in significant memory consumption while the compressed payload is expanded.Herb Sutter on increasing safety in C++
> Do it from a few clients and and you got your memory full :)
Herb Sutter on increasing safety in C++
see CVE-2003-1564 (billion laughs attack)
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
>the number of CVE's compared to Rust with just 10:1 actually sounds very low. Relatively speaking.
2) An actual memory safety vulnerability.
It takes 1) and 2) at the same time to have an incorrectly functioning program.
If you hand out two mutable references to an object that violates 1). But if you don't actually *use* these two references at the same time, then 2) is not happening. So you can have a CVE, but no actual vulnerability.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
The numbers speak for themselves and Rust is a capable alternative for even the hardcore cases. It's time for C/C++ to retire.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> Much of Rust's UB corresponds exactly to LLVM UB
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
> Thus claims like "C++ is so widely used" and "so many people know C++" always need to be qualified with which version of C++ is used or well-known.
Herb Sutter on increasing safety in C++
PhantomData affect variance of arguments and, heck, how to even properly use HRBTs?Herb Sutter on increasing safety in C++
> The Rust code I wrote 8 years ago is still, as far as I know, reasonably idiomatic today. Maybe there are some uses of the try! macro that should be ?, but that's trivial.
Herb Sutter on increasing safety in C++
async. Currently async is very much a bolt-on (like rvalue references in C++), but there are discussions about how to make code async-agnostic, and so on.Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Wol
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
I see this article as Sutter trying to persuade people to adopt the C++ Core Guidelines that he and Bjarne Stroustrup have been working on for several years. (It's nearly 300KB ... and they say up front that it still needs lots more work!).
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
- Me: Let me recheck it with Valgrind.
- Me: Our CI must be having issues.
- My colleague: Yes.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
I would rather rewrite code in Rust than to debug existing C++ code.
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
It would require a coherent concept of explicit and implicit lifetime annotations in the C++ code and the addition of strict rules such as mutable xor shared to the language.
That is the back bone of the borrow checker and most of the safe Rust features.
You would essentially transform C++ into Rust.
Why not use Rust then?
Herb Sutter on increasing safety in C++
Herb Sutter on increasing safety in C++
* If you "just" care about UAFs, buffer overruns, and the like, then mutable xor shared is less important for C++, specifically because C++'s move semantics are far weaker than those of Rust. In Rust, a move is a bitwise copy followed by immediate deallocation (the original becomes inaccessible and, from the language's perspective, effectively ceases to exist). Rust has to guarantee that there are no references to the original before it may allow a move, because otherwise you could UAF the original. In C++, a move is a copy that is allowed to mutate the original in arbitrary ways as long as it remains a valid instance (in practice, by "stealing" resources owned by the original). The original is not immediately deallocated or rendered inaccessible, and its destructor still runs (unless the move is elided). In order to allow for this, most C++ types with nontrivial destructors have Option<T>-like semantics (they have an "empty" state), or else they do not implement optimized move semantics (in Rust terms, they are Copy). So C++ would not need to prevent moving from a borrowed object to prevent UAF. It just has to ensure that object is not destructed before its references.