471–480 of 504 posts
Earlier quoted context omitted.
None of the safety issues brought up about C there are solved by C++. C++ is (nearly) a superset of C, so it inherits all of those issues.
If C++ is "(nearly) a superset of C" why is the C++ standard twice the size of C standard? Of course if we take that 0.505.. ≈ 1, then it is indeed a (nearly) superset.
Earlier quoted context omitted.
None of the safety issues brought up about C there are solved by C++. C++ is (nearly) a superset of C, so it inherits all of those issues.
If C++ is "(nearly) a superset of C" why is the C++ standard twice the size of C standard? Of course if we take that 0.505.. ≈ 1, then it is indeed a (nearly) superset.
Earlier quoted context omitted.
> I ask this in bad faith: I encourage you to share a single nontrivial codebase which actually creates the abstraction you've described and religiously adheres to using it throughout. As to why this is in bad faith: I'm definining "nontrivial" here to mean using 3rd party APIs - which will operate on C style arrays, not your project specific safe wrappers - and thus by definition won't be "religiously" sticking to s…
> I work on a C codebase that does this […]. Yes, there is quite a lot of NIH. With essentially-uniform use of checked data structures, and an extremely comprehensive suite of automated tests getting run under ASAN (originally Valgrind) […]. This is a complex, >1M SLOC distributed system that has seen several years of production use at this point […]. > > […] it just needs to be done from the start, and then you just…
Yes, but when the project started the only existing compiler that met all requirements was C (also C++, although that was not chosen, by reasoning I disagree with). We are in a domain where we derive material benefits from the low-level control C gives us (we have a bunch of highly specialized memory management and I/O), and are not willing to accept GC pauses. There's a common sentiment that we would have used Rust if it had existed when we started, but it didn't so we didn't and so it goes.
Earlier quoted context omitted.
The advantage is that you're depending only on yourself and C. That third party static analysis tool can just be "grep". Or some mild text processing on the output of "nm" to validate that no object files (other than the allowed ones) have external refs to those symbols.
Or just disallow platform headers.
And, honestly, one of the features is "vibrant community of developers." Even if Go and Rust were bad languages, which they're not, they'd still be better choices than C-with-custom-in-house-restrictions-and-libc-wrappers, simply because of the communities around them. If you're writing in Rust, someone else has already written the safe C wrappers, and if they haven't, there's a community of people who will code-review your wrappers for safety and merge them into a centrally-maintained project, which is extremely useful.
I wish more mention of D would happen. It is compatible with C and C++ libraries and features GC without sacrificing the good things of C and C++. I always loved the idea of Rust and Go but they are nowhere near C or C++ where it matters to me. D fits the bill, otherwise I just use Python. I like being able to design software in my own way as opposed to being told how to do it.
Last time I took a look at D I was awed by how terrible it's documentation is.
Earlier quoted context omitted.
Or just disallow platform headers.
Again, if you're disallowing platform headers and writing tooling to make sure you're never calling libc, what's the advantage of writing in C? You have all the headaches of switching to a new language, with none of the features. And, honestly, one of the features is "vibrant community of developers." Even if Go and Rust were bad languages, which they're not, they'd still be better choices than C-with-custom-in-house…
To answer your question though, the advantage of using C is certainly not the notorious bad-habits standard library. C is fun and productive exactly where there's just you and some bits and bytes to bang around. Coding in the small. Not platforms and architectures.
Earlier quoted context omitted.
That's a great quote, and it's one that Rust---as a a memory safe language---completely embraces. You have the freedom to do anything you want. Some of those things simply require you to type "unsafe."
Forgive me for being cheeky, but just as Rust requires you to type "unsafe," C also requires you to opt in by typing "cc". My serious point is that in practice, the example of C shows that if it is available and people understand that it is "performant" then you will see it all the time, including in libraries you are forced to use.
Earlier quoted context omitted.
People rely heavily on software in many aspects of their lives. They entrust it with their personal information, their money, and in many cases their physical safety. Engineers building software and companies selling it are ethically obliged to make a good faith effort to prevent defects that might betray their users' trust and cause harm. Languages designed to enhance the safety and security of software written in t…
Are engineering standards for public buildings evil because they stifle architects' freedom to design whatever crazy structures tickle their fancy? The physical analogy is good because even there one can see that there are different standards --- and, unlike what the "safe software" community seems to promote, engineers are not doing the equivalent of making every building strong enough to withstand a nuclear war and…
You can extend that absolutist argument to say that inventing anything that could be used as a tool of oppression is unethical. Like, inventing plumbing may have done great things for human society, but it was ultimately unethical because when the police came to take away your general-purpose computer they used a pipe to hit your kneecaps until you told them where it was. Or, how about this: developing any society beyond the level of the most primitive hunter-gatherer tribe is unethical, because what are governments if not the agents of oppression themselves?
This is the sort of abstract position that can't really be argued with in a vacuum, so I'm not going to try. But it's also not a useful ethic for building a modern society free of large-scale oppression, because it completely ignores the practical realities of doing so.
In the mean time, buggy, exploitable software is out there in the real world hurting real people every day.
Earlier quoted context omitted.
Just because people fail to do something doesn't mean it's not both possible and easy.
obviously decades of security advisories means it's not easy. what in the world does 'easy' mean in your current usage? surely "tons of failures" is a better indicator of difficulty than "it feels easy to me / that's 'naturally how my brain works'," etc. and of course, if lots of people fail at something, it will get proportionally harder with a larger team / larger codebase / different stakeholders demanding xyz, et…
I mean people manage to do a lot of dangerous things due to sloppiness - cause car accidents, for example. I don't think it's hard to avoid that, and I don't think those people should be driving. I suppose others think we need wider roads and bumper cars.
Earlier quoted context omitted.
I'm not sure where you're under the impression that the number of times something is explicitly mentioned corresponds directly to the number if times it's being discussed, which is what is implied by your suggestions to search for occurrences of the name. The whole article is about future plans for NTPsec, and the work going into making it so it can be converted to a new language later. The article is about the relat…
For me, this is the gist of the article: >> But NTPsec is a lot smaller and cleaner now at 62KLOC of C (that’s just 27% of the original size). It’s been brought up to pretty tight C99/ANSI standards conformance, and the few remaining platform dependencies are either already well isolated or can easily be made so. Then they have a section about future plans and a short comparison of two possible languages. I'm surpris…