Earlier quoted context omitted.
[flagged]
Wild accusations without any backup... please don't.
History has been written. What makes you the future will be different?
Why Safety Profiles Failed
121–130 of 233 posts
Re: Why Safety Profiles Failed
#122"No mutable aliases" is a mistake; it prevents many useful programs. Now that virtual address space is cheap, it's possible to recompile C (or presumably C++) with a fully-safe runtime (requiring annotation only around nasty things like `union sigval`), but this is an ABI break and has nontrivial overhead (note that AddressSanitizers has ~2x overhead and only catches some optimistic cases) unless you mandate addition…
How would this fix memory safety issues like std::sort(vec1.begin(), vec2.end()) (where vec1 and vec2 are different vectors, of course)? Or strlen(malloc(100))?
It seems to me that it would handle the sort case fine, you would read/write an invalid page and it would fall over(assuming all allocations had invalid pages at the end of the allocation & no 2 allocations share a page).
The strlen could be made safe by having the malloc return the address 100 bytes before the end of the page. If it did make it to the end of the 100 bytes it would fall over safely. Result would be nonsense of course. Of course if you read bytes < than the returned ptr you would have 4k-100 bytes before it fails on bad page.
Re: Why Safety Profiles Failed
#123Earlier quoted context omitted.
> But not everyone is interested in introducing a second toolchain, for example. Not that this invalidates your broader point about Safe C++, but this particular issue could also be solved by Rust shipping clang / a frontend that can also compile C and C++.
I have long thought that rust needs to copy Zig here but nobody seems to want to do it, so…
pip install rust
Re: Why Safety Profiles Failed
#124Earlier quoted context omitted.
The thing is, if you were to make the same design in C++ the code might look "cleaner" because there is less code/fewer annotations, but the other side of that coin is that the developer also has less information about how things are meant to fit together. You not only lose the compiler having your back, you also don't have useful documentation, even if that documentation would be too complicated to grasp at once. Wi…
That's a good point. There's many times in a C++ codebase, where I'd see or write a seemingly innocuous function, but it has so many assumptions about lifetimes, threads, etc that it would make your brain hurt. Of course we try to remove those or add a comment, but it's still difficult to deal with.
There are reasonably good c++11 conventions for lifetimes - if it is a unique_ptr you own it, otherwise you don't and shouldn't save a copy. Almost nobody follows them, but they are good conventions and you should, and write up a bug if someone else isn't. Similar, for threads, keep your data confined to one thread, but explicit where you move/copy it to a different thread (note I said move or copy - the first thread should lose access in some way) - with the only exception of data explicitly marked as thread safe.
The above is forced by Rust, which would be nice, but the conventions are easy enough if you try at all. But most developers refuse to write anything more than C++98.
Re: Why Safety Profiles Failed
#125At this point I'm wondering if the purpose of safety profiles is simply to serve as a distraction. In other words, safety profiles are just something people can point to when the topic of memory safety comes up, that’s it. The objectives of the initiative always seemed hopelessly optimistic, if not absurd. In particular, I don't understand why littering a codebase with auto, const, constexpr, inline, [[nodiscard]], n…
It's a tick-the-box-for-compliance item like when Microsoft had a POSIX layer for Windows NT.
Microsoft eventually learned that keeping full POSIX support would have been a better outcome in today's server room if they had done it properly instead.
Likewise, pushing half solutions like profiles that are still pretty much a paper idea, other than what already exists in static analysers, might decrease C++'s relevance in some domains, and eventually those pushing for them might find themselves in the position that adopting Safe C++ (circle's design) would have been a much better decision.
The problem with ISO driven languages, is who's around in the room when voting takes place.
Re: Why Safety Profiles Failed
#126Earlier quoted context omitted.
> The idea that sustained bugfixing could occur on a project that was not undergoing active development is purely wishful thinking yet the idea that a project no longer actively developed will be rewritten in rust is not?
> yet the idea that a project no longer actively developed will be rewritten in rust is not? Rewriting it in Rust while continuing to actively develop the project is a lot more plausible than keeping it in C++ and being able to "maintain a stable codebase" but somehow still fix bugs. (Keeping it in C++ and continuing active development is plausible, but means the project will continue to have major vulnerabilities)
I'm not convinced. Rust is nice, but every time I think I should write this new code in Rust I discover it needs to interoperate with some C++ code. How to I work with std::vector in rust - it isn't impossible but it isn't easy (and often requires copying data from C++ types to Rust types and back). How do I call a C++ virtual function from Rust?
The above issue is why my code is nearly all C++ - C++ was the best choice we had 15 years ago and mixing languages is hard unless you limit yourself to C (unreasonably simple IMO). D is the only language I'm aware of that has a good C++ interoperability story (I haven't worked with D so I don't know how it works in practice). Rust is really interesting, but it is hard to go from finishing a "hello world" tutorial in Rust to putting Rust in a multi-million line C++ program.
Re: Why Safety Profiles Failed
#127Earlier quoted context omitted.
For new projects on mainstream architectures that don't have to depend on legacy C++ baggage, Rust is great (and, I think, practically always the better choice). But, realistically, C++ will survive for as long as global technological civilization does. There are still people out there maintaining Fortran codebases. (also, IDK if you already realized this, but it's funny that the person you're replying to is one of t…
I have realized this. Sean and I have talked about it. I became a Rust fan because of its innovations in the space. That its innovations may spread elsewhere is a good thing, not a bad thing. If a language comes along that speaks to me more than Rust does, I’ll switch to that. I’m not a partisan, even if it may feel that way from the outside.
Indeed, even if Rust disappeared tomorrow, I would assert that its biggest contribution has been to make affine type systems more understanable in mainstream, to the point several languages, including a few with automatic memory management, are adding such concepts to their type systems without having their communities running away in horror, rather embracing the experiment.
Re: Why Safety Profiles Failed
#128These considerations all seem so self-evident that I can't imagine the architects of Safety Profiles weren't aware of them; they are basically just the statement of the problem. And yet these smart people presumably thought they had some kind of solution to them. Why did they think that? What did this solution look like? I would be very interested to read more context on this.
> Why did they think that? What did this solution look like?
I don't think they did think that. Having listened to a few podcasts with the safety profile advocates I've gotten the impression that their answer to any question about "right, but how would you actually do that?" is "well, we'll see, and in general there's other problems to think about, too!".
Re: Why Safety Profiles Failed
#129"No mutable aliases" is a mistake; it prevents many useful programs. Now that virtual address space is cheap, it's possible to recompile C (or presumably C++) with a fully-safe runtime (requiring annotation only around nasty things like `union sigval`), but this is an ABI break and has nontrivial overhead (note that AddressSanitizers has ~2x overhead and only catches some optimistic cases) unless you mandate addition…
> "No mutable aliases" is a mistake; it prevents many useful programs. Yes, it prevents many useful programs. I think it also prevents many many many more useless broken incorrect programs from wreaking havoc or being used as exploit delivery vehicles.
Writing correct mutable code when there are alias in play is difficult and should be avoided I agree. However sometimes it is the right answer to the problem and so it should be possible for the best programmers to do. However only a minority of code needs that, and when it is needed you need to do a lot of extra review - I wish there was a way to make doing it accidentally impossible on C++.
Re: Why Safety Profiles Failed
#130Earlier quoted context omitted.
Circle is a C++ compiler by Sean Baxter, with various extensions. One of those is an implementation of the Safe C++ proposal I’ve linked downthread.
Does the Circle compiler see any real-world use? I keep hearing about it, but it seems like it is a one-person project which hasn't seen significant activity in about a year. On paper it does sound quite promising, but looking at the Github repo I can't help but shake the feeling that it is more talk than action. It seems to have basically been abandoned before it ever saw any adoption?
At least Circle is real, something that one can download, validate its ideas, what works, what does not.
Most of the profiles being argued for C++ only exist in PDF form, there isn't a single C++ compiler where you can validate those ideas, but trust the authors, the ideas will certainly work once implemented.