22 ms·

C is like asbestos. It was fine at what it did, good performance, but the safety problems outweigh them. The difference is that we _stopped using asbestos_ beca

C is like asbestos. It was fine at what it did, good performance, but the safety problems outweigh them. The difference is that we _stopped using asbestos_ because it was unsafe. It’s still around but being replaced during renovations, and no new installations use it. For whatever reason with C there’s this huge emotional component to it. Safer alternatives exist. You’d rightfully laugh at a contractor who suggested asbestos is fine, if you make sure to use only highly-skilled installers who patch up the drywall so that no fibers can escape. But with C we say that all the time, and the CVEs keep piling up.

jimlongton 4y ago
> Safer alternatives exist. Sure, but do they have certified compilers for Functional Safety (ISO26262) development for Automotive or Medical applications? Rust does not, although there's a company working on it.
- docandrew 4y ago
  Yes, the compiler used for the work described in the post: https://www.adacore.com/industries/automotive/iso26262 https://www.adacore.com/industries/automotive/iso26262
sokoloff 4y ago
There are still industrial uses of asbestos today, because for some applications, there isn't a ready drop-in replacement. Uses where safer drop-in replacements were possible (shingles, automotive friction materials, flooring, insulation) have gone away. That might be a good comparison against "portable assembly", also known as C.
- vanattab 4y ago
  Out of curiosity what are the modern uses for asbestos?
  - Agrue8u 4y ago
    https://www.propublica.org/article/asbestos-poisoning-chemical-plant-niagara-falls https://www.propublica.org/article/asbestos-poisoning-chemic...
- blagie 4y ago
  I think the problem NVidia has is that it has a massive low-level high-performance computing infrastructure written in C. Things like WebGL are a thin veneer over it, which is terrifying. Their use combines the proper use of C (low-level driver code) with the unsafe use (large-scale systems). They should absolutely stop using C. On the other hand, I think it's fine for my network driver.
  - paulmd 4y ago
    I was talking with someone in charge of coordinating WebGL rollout with various IHV driver teams and they said while AMD and NVIDIA were definitely annoyed at the work it was going to take, Intel was the one where the team reacted with sheer terror. Maybe that speaks to some of the driver problems they're having now, if their house just wasn't in order beforehand.
    - blagie 4y ago
      The cynic in me says that Intel is the only vendor of the three who has thought about security before. I am willing to bet that NVidia and AMD's GPU unit have floodgates of vulnerabilities along the lines of Spectre, which they simply never had to deal with before (not to mentions likely hundreds of more basic ones).
      - paulmd 4y ago
        > I am willing to bet that NVidia and AMD's GPU unit have floodgates of vulnerabilities along the lines of Spectre, 100%, I'm not anybody important but I've been saying this for years, as soon as I saw Spectre/Meltdown announced it's like "lol yeah I bet GPUs are even worse, everyone is just racing for performance and not timing-correctness so they probably have zero hardening against that". I hadn't thought of the connection between Meltdown and that person's comment but yeah it's entirely possible they saw the potential for that or other security shenanigans. Multi-tenant or multi-privilege-level GPU is likely a shitshow, so in a way it's actually a blessing that heavy GPGPU compute never really took off. Because I bet you can totally do things like leak the desktop or your browser windows to malicious webGL or another tenant on a shared vGPU. We live in a world where clients are mostly running one GPGPU application at a time, plus the desktop, and that means there's nothing there to leak. (Although of course, it's always a little useless to speculate about massively counterfactual scenarios and assume everything would have gone the same... if multi-tenant/multi-app GPGPU compute had taken off, more attention probably would have been paid to multi-user security/hardening.) Of course the real game-over is if you can get the GPU to leak CPU memory (or get the GPU to get the driver stack to leak kernel memory/etc via the CPU). That's bad even without multi-tenant. Intel in particular may also be more vulnerable to that sort of thing since they have uniquely tight ties between the iGPU and the CPU. They come from a world where dGPUs didn't exist and the iGPU was only ever a ringbus away from memory or the CPU... it's apparently been a huge problem with the Xe/Arc drivers (there have been a couple patches where they produced 100x speedups by fixing operations that allocate memory in the wrong place, etc) since the GPU is suddenly no longer super close. It would not surprise me at all if AMD would be more secure because they're not working with an iGPU that's super tightly tied to the CPU like that. https://www.pcworld.com/article/819397/intels-graphics-driver-flub.html https://www.pcworld.com/article/819397/intels-graphics-drive... That's super funny you bring that up, thanks for tickling that particular neuron. Great comment and again, just a rando who tech-watches for fun, but, I agree 100%.
Workaccount2 4y ago
Forgive my ignorance, I'm a hobby embedded programmer at best, but aren't many programming languages built right on top of C? Is the whole lineage unsafe, or is it really just C?
- M4v3R 4y ago
  Not really. Many programming languages compile themselves nowadays (it's called bootstrapping) so there's no direct C lineage in them.
  - NekkoDroid 4y ago
    Slight correction: Programming languages compiling themselves is calls selfhosted. The process getting to that point (ie first making something that compile the language so you can compile the language with itself) is called bootstrapping. (at least that is how I know it as)
- gnarbarian 4y ago
  yes. if the compiler was written in c and there is a bug in the compiler that language could be tainted.
- AlotOfReading 4y ago
  Anything where a human is writing C is probably unsafe. Machine generated C can also be unsafe, but I'm unaware of an epidemic of systematic issues resulting from it the way we get with human C.
- pannSun 4y ago
  When people say "C is unsafe", what they mean is "it is too easy to create unintended vulnerabilities when writing C". The language won't catch your mistakes, and some of those mistakes are dangerous. "Safety" in this context means "language, compiler, or runtime features to prevent, catch, or mitigate mistakes made by human programmers". So this doesn't actually affect things built on top of C. E.g. transpiling Rust to C won't make it any less safe because C is "unsafe" - Rust has its own safety features, that work regardless of compile target. Or think of it this way - assembly language is even more unsafe than C, yet everything (including C) is built on top of that.
c-baby 4y ago
Are there really good alternatives to C? You can use Rust where you can use C, but the memory safety doesn’t come for free. A lot of people find Rust extremely annoying to write. Maybe something like Zig? But the ecosystem isn’t that big…
myth_drannon 4y ago
Ouch, that's a hurtful analogy. I was about to start playing with Turbo C on my 486, ordered K&R book...
- smcl 4y ago
  I think it is a little bit melodramatic as an analogy. It's perfectly fine to tinker with C, to use it in personal projects, to use it where it's not possible to use something safer (some embedded system that Rust doesn't have a backend for) or if you want to contribute to an existing project like Linux, OpenBSD or CPython. Whereas it's really not a good idea to work with Asbestos under any circumstances. But the message overall - that maybe we don’t need to instinctively reach for C for newbuild low-level programming anymore - is probably about right
- docandrew 4y ago
  As long as it doesn’t have a modem you’re probably safe. Probably.
- lelanthran 4y ago
  > Ouch, that's a hurtful analogy. It's also wrong. A lot of the time the people making these types of comments about C are just plain bitter that their favourite $NEW_LANGUAGE is mostly a rounding error in terms of usage.
  - wiseowise 4y ago
    > A lot of the time the people making these types of comments about McDonald’s are just plain bitter that their favourite $3_STAR_MICHELIN_RESTAURANT is mostly a rounding error in terms of visitors.
    - lelanthran 4y ago
      > A lot of the time the people making these types of comments about McDonald’s are just plain bitter that their favourite $3_STAR_MICHELIN_RESTAURANT is mostly a rounding error in terms of visitors. That's true too; what's your point?
georgeecollins 4y ago
That's a great analogy. I like C, and when people resist it I worry about their programming skills. That may not be fair, but sometimes the complexity of C / C++ is a version of complexity you will see in a big application.Sometimes the complexity is needless, confusing, dangerous-- insert what you hate here. But really Rust seems to have the qualities I like about C and less problems. Also, all the reasons I used to have for wanting to be "close to the metal" are getting abstracted away in hardware. I think the only remaining reasons to use C is the huge existing code base.
- 3a2d29 4y ago
  Although the article is about Ada, which is technically more memory safe than rust.
  - tmtvl 4y ago
    I'd like to see the Ada guys, and especially the SPARK guys, talk about Rust the way Rust people talk about C. That said, I'm just gonna add ACL2 to my Common Lisp toolbox and then I too will have the power of theorem proving.
- flohofwoe 4y ago
  A couple of points from somebody who enthusiastically writes new C code every day: > ...the complexity of C / C++ In this case, please don't throw C and C++ into the same bucket, C++ is vastly more complex than C. > Rust seems to have the qualities I like about C ...a subset of Rust has those qualities, but the whole of Rust has the same problems as C++: overboarding complexity both in the language and stdlib. To lure C users over to a memory-safe language, we need a programming language that just adds the comptime memory-safety features to a 'small language' like C, but none of the higher level features (which only serve to split the language community into different tribes - which is also the biggest problem of C++). Finally: yes, C is not memory safe, but when 'language-level memory safety' is essential for security, then there's something fundamentally wrong with the sandbox the compiled C code runs in.
  - 4y ago
nspattak 4y ago
In my opinion, the problem is that we failed to create some additional layers on top of C. an extended std lib with data structs and algorithms as well as a style/practices for everyday use (ie non compiler writers). i adore C, it was my first language and i still like its simplicity very much. Still, I have come to believe that only strictly vetted licensed people should be allowed to use it :)
- pclmulqdq 4y ago
  There are an incredibly large number of analysis tools for C to check things like memory safety. It doesn't look like they are always used in important code, though. A lot of memory safety CVEs come down to "we wrote a static analyzer and found a latent memory bug here."
  - timbit42 4y ago
    Maybe a language with the checking by default in the compiler would be a good idea, like Ada or SPARK.
- ilyt 4y ago
  That doesn't stop bugs, that just makes them less likely. VS making them impossible on accident
spenczar5 4y ago
This is not a very useful analogy. It suggests that we should regulate C out of existence. But regulation was appropriate and effective for a particular reason with asbestos. We stopped using asbestos because of the link between its manufacture/installation and lung cancer. It’s a clear case where government regulation helps deal with a market failure: asbestos is cheap and effective, so consumers like it, but nobody involved in asbestos transactions bears the cost of the lung cancers the industry causes. Writing C doesn’t make underpaid programmer die early deaths. The issues with C are borne directly by the customers who are using C software. It’s not really a market failure of any kind.
- docandrew 4y ago
  I don’t think the federal government should step in and regulate it, but why not some kind of professional or trade organization, like UL? And really, I think your argument bolsters my case. Federal and state governments are freaking out about cybersecurity and protecting infrastructure and voting systems, so why shouldn’t they ban the use of software written in C in their acquisition process?
  - flohofwoe 4y ago
    Such regulations already exists, see for instance https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C. Similar rules could be created for Rust (I would assume that this would have to be some sort of 'sane subset' of Rust, which for instance would forbid dynamic memory allocation alltogether).
    - topdancing 4y ago
      Or you could use https://en.m.wikipedia.org/wiki/SPARK_(programming_language) https://en.m.wikipedia.org/wiki/SPARK_(programming_language) which is already a formal defined language and literally the thing discussed in the link right at the top.
- deleted 4y ago
  [deleted]
mumblemumble 4y ago
It's not an emotional component, it's just plain old network effects. Unfortunately, a lot more switching cost is involved in getting embedded and systems programmers and platforms over to a new programming language, than is involved in getting construction contractors and industrial engineers to choose a different material.
- mmis1000 4y ago
  Lots of them just have their own toolchain and language subset. Make porting literally impossible. Because you don't know how the original one works. And c like language on these embedded devices are probably due to the fact that it's the easiest way to implement a programming language(abstraction) that work on bare metal.
bitL 4y ago
I despise this security-first attitude. It just leads to so much mental fatigue everywhere and any step is a potential minefield. It's ruining programming.
- ironmagma 4y ago
  > any step is a potential minefield That's the exact problem with C. It's the tool, not the attitude, which is a problem.
  - flohofwoe 4y ago
    Securely containing untrusted user code so that it can't do any harm is ultimately the responsibility of the OS, or whatever sandbox the code is running in. Language-level memory safety is useful for eliminating an important class of bugs, but if those bugs can be exploited to escape the sandbox, then that's the problem of the sandbox, not of the buggy program running in that sandbox. So please, by all means, write the sandbox itself in a memory safe language like Rust, but requiring the same for all code running inside the sandbox is nothing more than an admission of failure.
    - timbit42 4y ago
      What if the sandbox, kernel, device drivers are written in C? Sounds like a good case against C for these uses.
      - flohofwoe 4y ago
        Yes, I fully agree! But such subtleties are usually overlooked by the 'C users are criminals' crowd ;)
    - ilyt 4y ago
      That's pretty limited way to look at it. You don't need to escape the sandbox to do harm. You can have your app in perfect sandbox where nothing can escape then have a memory safety bug inside allowing user to get to the stuff of another user (because your sandboxed app talking with sandboxed database still have one set of credentials to do everything) There is of course https://xkcd.com/1200/ https://xkcd.com/1200/ for that. And no "move that separation to DB" also isn't a solution.
lelanthran 4y ago
> For whatever reason with C there’s this huge emotional component to it. Frankly getting your knickers in a knot is emotional - the people using C are doing so for pragmatic reasons, not emotion. I do see comments like yours a lot - there's an emotional attachment and/or ego attached to the comment, so the argument against is very vociferous and, honestly, ugly[1]. [1] C and asbestos have almost nothing in common in terms of negative impact on the world. Maybe people are still using C because hyperbole is simply not a persuasive argument.
- meltyness 4y ago
  You don't seem to address the "pragmatic reasons" expressly, so I'll go ahead and do it: 1. "Don't rewrite code" a fundamental precept of software that has been "engineered" - This is more about development lifecycles than something that contributes usefully to software quality in the long term. Corporations, and people haven't been treating these things like bridges or overpasses 2. Outsourcing is believed cheaper than the solution. - Again, paying low-wage junior SEs to patch uncovered bugs is obviously cheaper than proactively finding them all. 3. You can sell the New Coke too! - If you have a good rewrite, sell it at a fat markup, and keep selling the old crap too, it's not your risk. - Obviously don't rewrite unless your horrid monolithic source leaks, and you're certain that it's a problem, those disgruntled workers you wrongfully laid off know too much. 4. If your tech references are a security risk, sell those too! - Don't include pesky manuals where people can uncover issues with your development processes, outsource a minimum blackbox of guess work to Singapore and let that double as QA. - It's not a manual, it's 'training' -- supporting education of hopeful workers! Wow! I won't name any names.
- zamalek 4y ago
  > I do see comments like yours a lot - there's an emotional attachment and/or ego attached to the comment Could you explain how it's emotional? It comes across as a pretty logical analogy to me - the author isn't suggesting that they don't like C (which would be categorically emotional), they are comparing it to phasing out something unsafe in another industry.
  - 4y ago
delusional 4y ago
Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. I work in a fairly large (for my country) financial institution and the problems we deal with on a day to day basis are so far removed from buffer overflows that it's not even funny. We still have software running in excel macros that control web browsers via COM. C is nothing compared to the attack surface of that.
- docandrew 4y ago
  Ok, but why are the Excel macros so risky? It’s often because the underlying software or OS was written in C/C++.
  - snicker7 4y ago
    You can be socially engineered to open a mallacious excel.
  - delusional 4y ago
    What? No it isn't. It's because the users think they're opening a document to look at some data and suddenly it's an executable transferring money via their bank account. And that's all working as designed. Someone built it like that. There's no bug anywhere in that chain, just as extremely rickety system with no affordances for human intervention. No separation of what is trusted and what is not.
  - Jtsummers 4y ago
    Excel macros are risky because they offer a kind of privilege escalation. Most Excel built-in functions (that is, what you write into the cells) have limited reach. They impact that cell and (by reference) other cells, but not the underlying filesystem and other things. Even looking at the database ones, I'm not seeing a single function that writes to the DB but plenty that read from it, that's "safe" in that it would be very hard to abuse these kinds of things to screw with other systems or the host system. But macros can run arbitrary code and access whatever the user can access in a way most Excel functions cannot and can trigger arbitrary effects. The equivalent of `rm -r ~/` is not possible in straight Excel, but is feasible with a macro. C and C++ have nothing to do with that, it's the underlying privilege model that permits it. There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.
encryptluks2 4y ago
- deleted 4y ago
  [deleted]
- potta_coffee 4y ago
  I've never given Rust a chance because I'm utterly repulsed by the community.
  - encryptluks2 4y ago
    I actually am quite please with it, or at least the programs I've used written in Rust... but the community has been pretty toxic and it hasn't been without its share of security vulnerabilities.
epistasis 4y ago
I think a better analogy may be nuclear power, than asbestos, because of the labor side of the tech. Using nuclear power correctly takes a ton of engineering prowess, lots of additional construction. If done well, it works great. When it goes bad, it goes really bad. So if it's 1982, maybe nuclear power or C is a good option. If it's 2022, new technology may provide a cheaper way of getting to the same end point, with less engineering and construction, and probably even less cost.
- deleted 4y ago
  [deleted]
- adgjlsfhk1 4y ago
  This is a worse analogy because good nuclear plants exist. With C, I've yet to see a widely used library written by multiple humans in C that doesn't have critical memory bugs.
  - fxtentacle 4y ago
    Linux comes pretty close for practical usage. Or sqlite.
    - adgjlsfhk1 4y ago
      https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... and https://www.cvedetails.com/vulnerability-list.php?vendor_id=33&product_id=47&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=1&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=2022&month=0&cweid=0&order=3&trc=25&sha=0c6bafc0d41433be31a10f04664962b64905ce4f https://www.cvedetails.com/vulnerability-list.php?vendor_id=.... Linux has new security vulnerabilities found every year due to memory issues caused by C.
  - Schroedingersat 4y ago
    Those C code bases all get used and many have lives depending on them. Generally the really bad disasters are almost always narrowly avoided before they come to public attention. Why would your experience there make you think the good nuclear plants are any different?
tomp 4y ago
> Safer alternatives exist. Do they? The only “safe” comparable alternative is unsafe Rust which as the name suggests isn’t actually safe.
- jesse__ 4y ago
  You're right. Alternatives that tick all the boxes that C does, and are also safer, do not exist. This guy is just doing the typical religious yelling about people doing their jobs (writing kernels, drivers, browsers, games, etc) with the most flexible tool for programming we've developed to date. Maybe one day Rust will become dominant. Maybe someone will overhaul the aliasing rules of C, write some similar lifetime tracking tooling, and it will live on for another 50 years. Who knows. The reason people still use C and C++ isn't because they're good languages (or even that people like them, as the comment states), it's that until recently there have been very few viable alternatives, and for some domains literally none at all. They've largely been the only option for a long time.
  - notriddle 4y ago
    The article is about Ada SPARK, and nVidia using it to develop their firmware today.
    - jesse__ 4y ago
      Yes, I wasn't referring to the article, I was referring to the person comparing C to asbestos. It makes sense for nVidia to trade development time and prefer a language with formal verification for their firmware.
- nordsieck 4y ago
  > The only “safe” comparable alternative is unsafe Rust which as the name suggests isn’t actually safe. And for some applications, Rust isn't even an alternative. Not every chip is supported by LLVM.
- Gigachad 4y ago
  You typically don't have to write any unsafe Rust as an end user. The unsafe stuff is contained in very small and very rigorously analyzed standard library types. Which then provides you a safe interface to do all the stuff you normally do.
nordsieck 4y ago
> For whatever reason with C there’s this huge emotional component to it. Safer alternatives exist. For a lot of things, I just don't think this is true. For example, here is sqlite's reasoning for choosing C: https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html I can't say I can really disagree with it.
- wizofaus 4y ago
  That article wins the argument for me, and I'm not a fan of C particularly. Admittedly it doesn't address security concerns, but the fact they're able to achieve 100% machine code level branch coverage (I wonder if that includes the possibility of executing injected code...) should go a long way towards generating confidence that there are no readily exploitable vulnerabilities.
spamizbad 4y ago
There are many C developers out there who will insist they have gained enough experience to never write code vulnerable to various memory safety exploits. Real "I actually drive safer slightly buzzed" vibes.
- wiseowise 4y ago
  > Real "I actually drive safer slightly buzzed" vibes. “I don’t need seatbelts, I actually know how to drive unlike others”
  - abudabi123 4y ago
    phase out C on the schedule the internal combustion engine is going out of circulation as is being required
marcosdumay 4y ago
People also had a large and unexplainable emotional attachment to asbestos.
noobermin 4y ago
So it's not everything but as long as operating systems are written in C, it will be the language of choice for many projects.
kazinator 4y ago
We use all sorts of hazardous materials, which are safe if properly used, transported and stored. C is not "unsafe" in the sense that little bits of it break off in installations and make people sick, but in the sense that the assurance of safety almost all rests on the programmer. If code is safe, and not changed, it stays that way.
optymizer 4y ago
> It was fine at what it did No need to talk in past tense. C is still the best language at what it is meant for: writing fast software. Not safe software, _fast and portable_ software. > but the safety problems outweigh them Safety is to speed what security is to convenience. Frankly, most of the arguments I see today are just fear mongering. In my experience, there is no protecting users from developer mistakes that lead to software exploitation and 'unsafety', independent of the language being used. Memory issues are a common avenue, but if you take it away, the next issue will become the main avenue for exploitation, and you'll be back in the same spot, with the next generation of developers fearing that the new software safety level is insufficient to reach some ideal safety level, all while having traded off real world speed across the board to reach that point. > no new installations use it I'm writing a tool in C. It doesn't need to be perfectly secure. It does need to be fast. By using C we acknowledge that users want speed, more than they want safety, and that's our developer reality. That doesn't mean users don't want safety, it just means that outside of specialized domains, on average speed takes priority - people have been voting for decades that they want speed more than safety, and the process of deciding the priority is as you'd expect: users use money to buy a faster product and companies selling software invest in making their software fast first. The security argument is also weak. The whole point of cracking software is to find flaws in existing systems, regardless of the language they were coded in. One thing will always be true: anything that sends data can be cracked. You can only make the entry bar harder, but you will not create a language that is significantly safer and as fast as C because the optimizations that make software fast (like not checking array lengths, not checking for overflow, etc) are also the ones making it less secure. One can create a language that's safer than C and fast (in specific situations), but there will always be people cracking the core of whatever the 'safe' language du jour is, so you will have decreased security incidents on average, but have not eliminated them, while leaving room for a competitor to swoop in with a faster product that's safe enough, and it's your users who will decide who wins, not you. Just to emphasize this, so far, I have not seen any indication that the general population will shift to picking safety over speed, so you'd be betting against your users.
- c-cube 4y ago
  At this point there isn't strong evidence that C is going to deliver better performance than C++ or Rust, especially for a given amount of work. One could argue that better code reuse (templates, generics, crates, etc.) allow programmers to write faster code in C++ or rust. For example you need barely any work to use a really good hash table in rust, one that's really tricky to rewrite by hand because it involves simd and whatnot.
googlryas 4y ago
To adjust your analogy a little, we actually still use asbestos, but it just isn't used for the general public. It still has unique properties that are industrially or commercially useful, such as certain asphaltic roofing compounds and friction products like brake pads. But, it isn't used in products designed for the general public where strict oversight can't generally be provided.
- ethbr0 4y ago
  This is the key point that's often missed: asbestos isn't used anymoee in applications where the risks outweigh the benefits. We use incredibly dangerous materials in photolithography, nuclear weapons production, armor piercing projectiles, and aerospace... because there are no alternatives and/or the benefits outweigh the risks. What changed is that we learned more about asbestos (it causes cancer) and phased it out of applications where alternatives existed, even more expensive ones. In the C analogy, there may be places C continues to make sense... but it shouldn't be used anymore out of default, because it's the way things have always been done, or any other reason that doesn't end with "... and that's more important than an increased risk of security vulnerabilities."
hackerbrother 4y ago
More asbestos! More asbestos!
- paulmd 4y ago
  https://www.dailymail.co.uk/news/article-3091148/Chilling-image-shows-miners-playing-asbestos-shovelling-competition.html https://www.dailymail.co.uk/news/article-3091148/Chilling-im...
ploxiln 4y ago
C in software stacks is more like flame in kitchens. Fire is dangerous and bad for your health. Kitchen fires kill people, gas leaks kill people. It's possible to do without. But billions of people around the world cook with flame and do OK. All our ancestors did, and here we are. There will always be professional kitchens that use gas/flame (almost all of them). And it'll always be possible for your food to catch on fire anyway, if you cook it wrong. Unlike asbestos insulation in houses, or flame in your personal kitchen, you actually can't avoid C in your software stack. Do you use Linux, FreeBSD, or OpenBSD, or macOS, or Windows? Do you use Postgres or MySql or sqlite, or maybe redis or memcached? How about a language like Python or JS or Java or Ruby or Lua? Do you use rust? guess what the business-end of that compiler is written in! so you dabble at the tippy-top of the stack in some language like rust or go, so what?
- ClumsyPilot 4y ago
  > Unlike asbestos insulation in houses, you actually can't avoid C in your software stack You know what, construction industry could have made the same argument - oh look, all insulation suppliers use asbestos, the factory is built out of it too, its everywhere in the supply chain, you can't actually avoid asbestos if you ate trying to build a house, so we should learn to live with it. You can't avoid fossil fuels, you gave to use fossil fuels to produce a solar panel, so dreaming about clean energy is pointless. The difference is that some i industries pull the finger out of their bum and clean up their act, and some i dustries, like our's, does not. Even thoigh perfectly serviceable alternatives exist.
jstimpfle 4y ago
Depression can be bad, too. Maybe it can lead to cancer, and it undisputedly causes deaths. Other languages make me depressive and steal my focus. They make me go to great lengths trying to get the simplest things done. In C, it's like memset(p, 0, sizeof *p), done. Other languages make it such that I always code on 3 layers of abstraction to not have to do the "hard" task, but now I don't know the implementation of those layers. They make it such that I'm constantly torn to come up with an even more clever thing to say the same things, with even more abstractions and moving parts. They pull so much attention to themselves, distracting from the task that I want get done. With C, this is not the case. Maybe with a different personality, I could be similarly or even more productive in Rust, ignoring all the kitsch in its ecosystem. But I've started reading Rust projects dozens of times and have always turned away. They always use one more abstraction than I can be arsed to look up, always hide the most interesting and motivating parts behind a crate dependency. This is not the case with C, where it is easy to find good (enough) code that is honest and direct, and rewarding. I know that C is not perfect. We're having an open relationship, and I don't have any attachments (besides knowing it well) that prevent me from jumping ship when I find a better one.
qualudeheart 4y ago
MISRA C avoids those security flaws in a big way.
- TazeTSchnitzel 4y ago
  I wish that were true. It imposes a lot of restrictions but doesn't solve the fundamental issues of C.
raxxorraxor 4y ago
I have no emotion towards C. It is an old language and certainly an imperfect one. The thing is you just need to come up with something better. Maybe someday that can be Rust or another language. But you need something to replace it. This will not be a quick change. C is interoperable, and the industry is moving slowly.
mbrodersen 4y ago
There is a lot of software out there written in C. All of which needs maintenance. At work new C code gets checked in every day for software that runs major companies around the world. Having said that, I would never recommend C as the language of choice for new projects.

jimlongton 4y ago

> Safer alternatives exist. Sure, but do they have certified compilers for Functional Safety (ISO26262) development for Automotive or Medical applications? Rust does not, although there's a company working on it.

docandrew 4y ago
Yes, the compiler used for the work described in the post: https://www.adacore.com/industries/automotive/iso26262 https://www.adacore.com/industries/automotive/iso26262

sokoloff 4y ago

There are still industrial uses of asbestos today, because for some applications, there isn't a ready drop-in replacement. Uses where safer drop-in replacements were possible (shingles, automotive friction materials, flooring, insulation) have gone away. That might be a good comparison against "portable assembly", also known as C.

vanattab 4y ago
Out of curiosity what are the modern uses for asbestos?
- Agrue8u 4y ago
  https://www.propublica.org/article/asbestos-poisoning-chemical-plant-niagara-falls https://www.propublica.org/article/asbestos-poisoning-chemic...
blagie 4y ago
I think the problem NVidia has is that it has a massive low-level high-performance computing infrastructure written in C. Things like WebGL are a thin veneer over it, which is terrifying. Their use combines the proper use of C (low-level driver code) with the unsafe use (large-scale systems). They should absolutely stop using C. On the other hand, I think it's fine for my network driver.
- paulmd 4y ago
  I was talking with someone in charge of coordinating WebGL rollout with various IHV driver teams and they said while AMD and NVIDIA were definitely annoyed at the work it was going to take, Intel was the one where the team reacted with sheer terror. Maybe that speaks to some of the driver problems they're having now, if their house just wasn't in order beforehand.
  - blagie 4y ago
    The cynic in me says that Intel is the only vendor of the three who has thought about security before. I am willing to bet that NVidia and AMD's GPU unit have floodgates of vulnerabilities along the lines of Spectre, which they simply never had to deal with before (not to mentions likely hundreds of more basic ones).
    - paulmd 4y ago
      > I am willing to bet that NVidia and AMD's GPU unit have floodgates of vulnerabilities along the lines of Spectre, 100%, I'm not anybody important but I've been saying this for years, as soon as I saw Spectre/Meltdown announced it's like "lol yeah I bet GPUs are even worse, everyone is just racing for performance and not timing-correctness so they probably have zero hardening against that". I hadn't thought of the connection between Meltdown and that person's comment but yeah it's entirely possible they saw the potential for that or other security shenanigans. Multi-tenant or multi-privilege-level GPU is likely a shitshow, so in a way it's actually a blessing that heavy GPGPU compute never really took off. Because I bet you can totally do things like leak the desktop or your browser windows to malicious webGL or another tenant on a shared vGPU. We live in a world where clients are mostly running one GPGPU application at a time, plus the desktop, and that means there's nothing there to leak. (Although of course, it's always a little useless to speculate about massively counterfactual scenarios and assume everything would have gone the same... if multi-tenant/multi-app GPGPU compute had taken off, more attention probably would have been paid to multi-user security/hardening.) Of course the real game-over is if you can get the GPU to leak CPU memory (or get the GPU to get the driver stack to leak kernel memory/etc via the CPU). That's bad even without multi-tenant. Intel in particular may also be more vulnerable to that sort of thing since they have uniquely tight ties between the iGPU and the CPU. They come from a world where dGPUs didn't exist and the iGPU was only ever a ringbus away from memory or the CPU... it's apparently been a huge problem with the Xe/Arc drivers (there have been a couple patches where they produced 100x speedups by fixing operations that allocate memory in the wrong place, etc) since the GPU is suddenly no longer super close. It would not surprise me at all if AMD would be more secure because they're not working with an iGPU that's super tightly tied to the CPU like that. https://www.pcworld.com/article/819397/intels-graphics-driver-flub.html https://www.pcworld.com/article/819397/intels-graphics-drive... That's super funny you bring that up, thanks for tickling that particular neuron. Great comment and again, just a rando who tech-watches for fun, but, I agree 100%.

Workaccount2 4y ago

Forgive my ignorance, I'm a hobby embedded programmer at best, but aren't many programming languages built right on top of C? Is the whole lineage unsafe, or is it really just C?

M4v3R 4y ago
Not really. Many programming languages compile themselves nowadays (it's called bootstrapping) so there's no direct C lineage in them.
- NekkoDroid 4y ago
  Slight correction: Programming languages compiling themselves is calls selfhosted. The process getting to that point (ie first making something that compile the language so you can compile the language with itself) is called bootstrapping. (at least that is how I know it as)
gnarbarian 4y ago
yes. if the compiler was written in c and there is a bug in the compiler that language could be tainted.
AlotOfReading 4y ago
Anything where a human is writing C is probably unsafe. Machine generated C can also be unsafe, but I'm unaware of an epidemic of systematic issues resulting from it the way we get with human C.
pannSun 4y ago
When people say "C is unsafe", what they mean is "it is too easy to create unintended vulnerabilities when writing C". The language won't catch your mistakes, and some of those mistakes are dangerous. "Safety" in this context means "language, compiler, or runtime features to prevent, catch, or mitigate mistakes made by human programmers". So this doesn't actually affect things built on top of C. E.g. transpiling Rust to C won't make it any less safe because C is "unsafe" - Rust has its own safety features, that work regardless of compile target. Or think of it this way - assembly language is even more unsafe than C, yet everything (including C) is built on top of that.

c-baby 4y ago

Are there really good alternatives to C? You can use Rust where you can use C, but the memory safety doesn’t come for free. A lot of people find Rust extremely annoying to write. Maybe something like Zig? But the ecosystem isn’t that big…

myth_drannon 4y ago

Ouch, that's a hurtful analogy. I was about to start playing with Turbo C on my 486, ordered K&R book...

smcl 4y ago
I think it is a little bit melodramatic as an analogy. It's perfectly fine to tinker with C, to use it in personal projects, to use it where it's not possible to use something safer (some embedded system that Rust doesn't have a backend for) or if you want to contribute to an existing project like Linux, OpenBSD or CPython. Whereas it's really not a good idea to work with Asbestos under any circumstances. But the message overall - that maybe we don’t need to instinctively reach for C for newbuild low-level programming anymore - is probably about right
docandrew 4y ago
As long as it doesn’t have a modem you’re probably safe. Probably.
lelanthran 4y ago
> Ouch, that's a hurtful analogy. It's also wrong. A lot of the time the people making these types of comments about C are just plain bitter that their favourite $NEW_LANGUAGE is mostly a rounding error in terms of usage.
- wiseowise 4y ago
  > A lot of the time the people making these types of comments about McDonald’s are just plain bitter that their favourite $3_STAR_MICHELIN_RESTAURANT is mostly a rounding error in terms of visitors.
  - lelanthran 4y ago
    > A lot of the time the people making these types of comments about McDonald’s are just plain bitter that their favourite $3_STAR_MICHELIN_RESTAURANT is mostly a rounding error in terms of visitors. That's true too; what's your point?

georgeecollins 4y ago

That's a great analogy. I like C, and when people resist it I worry about their programming skills. That may not be fair, but sometimes the complexity of C / C++ is a version of complexity you will see in a big application.Sometimes the complexity is needless, confusing, dangerous-- insert what you hate here. But really Rust seems to have the qualities I like about C and less problems. Also, all the reasons I used to have for wanting to be "close to the metal" are getting abstracted away in hardware. I think the only remaining reasons to use C is the huge existing code base.

3a2d29 4y ago
Although the article is about Ada, which is technically more memory safe than rust.
- tmtvl 4y ago
  I'd like to see the Ada guys, and especially the SPARK guys, talk about Rust the way Rust people talk about C. That said, I'm just gonna add ACL2 to my Common Lisp toolbox and then I too will have the power of theorem proving.
flohofwoe 4y ago
A couple of points from somebody who enthusiastically writes new C code every day: > ...the complexity of C / C++ In this case, please don't throw C and C++ into the same bucket, C++ is vastly more complex than C. > Rust seems to have the qualities I like about C ...a subset of Rust has those qualities, but the whole of Rust has the same problems as C++: overboarding complexity both in the language and stdlib. To lure C users over to a memory-safe language, we need a programming language that just adds the comptime memory-safety features to a 'small language' like C, but none of the higher level features (which only serve to split the language community into different tribes - which is also the biggest problem of C++). Finally: yes, C is not memory safe, but when 'language-level memory safety' is essential for security, then there's something fundamentally wrong with the sandbox the compiled C code runs in.
- 4y ago

nspattak 4y ago

In my opinion, the problem is that we failed to create some additional layers on top of C. an extended std lib with data structs and algorithms as well as a style/practices for everyday use (ie non compiler writers). i adore C, it was my first language and i still like its simplicity very much. Still, I have come to believe that only strictly vetted licensed people should be allowed to use it :)

pclmulqdq 4y ago
There are an incredibly large number of analysis tools for C to check things like memory safety. It doesn't look like they are always used in important code, though. A lot of memory safety CVEs come down to "we wrote a static analyzer and found a latent memory bug here."
- timbit42 4y ago
  Maybe a language with the checking by default in the compiler would be a good idea, like Ada or SPARK.
ilyt 4y ago
That doesn't stop bugs, that just makes them less likely. VS making them impossible on accident

spenczar5 4y ago

This is not a very useful analogy. It suggests that we should regulate C out of existence. But regulation was appropriate and effective for a particular reason with asbestos. We stopped using asbestos because of the link between its manufacture/installation and lung cancer. It’s a clear case where government regulation helps deal with a market failure: asbestos is cheap and effective, so consumers like it, but nobody involved in asbestos transactions bears the cost of the lung cancers the industry causes. Writing C doesn’t make underpaid programmer die early deaths. The issues with C are borne directly by the customers who are using C software. It’s not really a market failure of any kind.

docandrew 4y ago
I don’t think the federal government should step in and regulate it, but why not some kind of professional or trade organization, like UL? And really, I think your argument bolsters my case. Federal and state governments are freaking out about cybersecurity and protecting infrastructure and voting systems, so why shouldn’t they ban the use of software written in C in their acquisition process?
- flohofwoe 4y ago
  Such regulations already exists, see for instance https://en.wikipedia.org/wiki/MISRA_C https://en.wikipedia.org/wiki/MISRA_C. Similar rules could be created for Rust (I would assume that this would have to be some sort of 'sane subset' of Rust, which for instance would forbid dynamic memory allocation alltogether).
  - topdancing 4y ago
    Or you could use https://en.m.wikipedia.org/wiki/SPARK_(programming_language) https://en.m.wikipedia.org/wiki/SPARK_(programming_language) which is already a formal defined language and literally the thing discussed in the link right at the top.
deleted 4y ago
[deleted]

mumblemumble 4y ago

It's not an emotional component, it's just plain old network effects. Unfortunately, a lot more switching cost is involved in getting embedded and systems programmers and platforms over to a new programming language, than is involved in getting construction contractors and industrial engineers to choose a different material.

mmis1000 4y ago
Lots of them just have their own toolchain and language subset. Make porting literally impossible. Because you don't know how the original one works. And c like language on these embedded devices are probably due to the fact that it's the easiest way to implement a programming language(abstraction) that work on bare metal.

bitL 4y ago

I despise this security-first attitude. It just leads to so much mental fatigue everywhere and any step is a potential minefield. It's ruining programming.

ironmagma 4y ago
> any step is a potential minefield That's the exact problem with C. It's the tool, not the attitude, which is a problem.
- flohofwoe 4y ago
  Securely containing untrusted user code so that it can't do any harm is ultimately the responsibility of the OS, or whatever sandbox the code is running in. Language-level memory safety is useful for eliminating an important class of bugs, but if those bugs can be exploited to escape the sandbox, then that's the problem of the sandbox, not of the buggy program running in that sandbox. So please, by all means, write the sandbox itself in a memory safe language like Rust, but requiring the same for all code running inside the sandbox is nothing more than an admission of failure.
  - timbit42 4y ago
    What if the sandbox, kernel, device drivers are written in C? Sounds like a good case against C for these uses.
    - flohofwoe 4y ago
      Yes, I fully agree! But such subtleties are usually overlooked by the 'C users are criminals' crowd ;)
  - ilyt 4y ago
    That's pretty limited way to look at it. You don't need to escape the sandbox to do harm. You can have your app in perfect sandbox where nothing can escape then have a memory safety bug inside allowing user to get to the stuff of another user (because your sandboxed app talking with sandboxed database still have one set of credentials to do everything) There is of course https://xkcd.com/1200/ https://xkcd.com/1200/ for that. And no "move that separation to DB" also isn't a solution.

lelanthran 4y ago

> For whatever reason with C there’s this huge emotional component to it. Frankly getting your knickers in a knot is emotional - the people using C are doing so for pragmatic reasons, not emotion. I do see comments like yours a lot - there's an emotional attachment and/or ego attached to the comment, so the argument against is very vociferous and, honestly, ugly[1]. [1] C and asbestos have almost nothing in common in terms of negative impact on the world. Maybe people are still using C because hyperbole is simply not a persuasive argument.

meltyness 4y ago
You don't seem to address the "pragmatic reasons" expressly, so I'll go ahead and do it: 1. "Don't rewrite code" a fundamental precept of software that has been "engineered" - This is more about development lifecycles than something that contributes usefully to software quality in the long term. Corporations, and people haven't been treating these things like bridges or overpasses 2. Outsourcing is believed cheaper than the solution. - Again, paying low-wage junior SEs to patch uncovered bugs is obviously cheaper than proactively finding them all. 3. You can sell the New Coke too! - If you have a good rewrite, sell it at a fat markup, and keep selling the old crap too, it's not your risk. - Obviously don't rewrite unless your horrid monolithic source leaks, and you're certain that it's a problem, those disgruntled workers you wrongfully laid off know too much. 4. If your tech references are a security risk, sell those too! - Don't include pesky manuals where people can uncover issues with your development processes, outsource a minimum blackbox of guess work to Singapore and let that double as QA. - It's not a manual, it's 'training' -- supporting education of hopeful workers! Wow! I won't name any names.
zamalek 4y ago
> I do see comments like yours a lot - there's an emotional attachment and/or ego attached to the comment Could you explain how it's emotional? It comes across as a pretty logical analogy to me - the author isn't suggesting that they don't like C (which would be categorically emotional), they are comparing it to phasing out something unsafe in another industry.
- 4y ago

delusional 4y ago

Believing that all software security problems would be solved if we got rid of C is a bigger disease than C itself. I work in a fairly large (for my country) financial institution and the problems we deal with on a day to day basis are so far removed from buffer overflows that it's not even funny. We still have software running in excel macros that control web browsers via COM. C is nothing compared to the attack surface of that.

docandrew 4y ago
Ok, but why are the Excel macros so risky? It’s often because the underlying software or OS was written in C/C++.
- snicker7 4y ago
  You can be socially engineered to open a mallacious excel.
- delusional 4y ago
  What? No it isn't. It's because the users think they're opening a document to look at some data and suddenly it's an executable transferring money via their bank account. And that's all working as designed. Someone built it like that. There's no bug anywhere in that chain, just as extremely rickety system with no affordances for human intervention. No separation of what is trusted and what is not.
- Jtsummers 4y ago
  Excel macros are risky because they offer a kind of privilege escalation. Most Excel built-in functions (that is, what you write into the cells) have limited reach. They impact that cell and (by reference) other cells, but not the underlying filesystem and other things. Even looking at the database ones, I'm not seeing a single function that writes to the DB but plenty that read from it, that's "safe" in that it would be very hard to abuse these kinds of things to screw with other systems or the host system. But macros can run arbitrary code and access whatever the user can access in a way most Excel functions cannot and can trigger arbitrary effects. The equivalent of `rm -r ~/` is not possible in straight Excel, but is feasible with a macro. C and C++ have nothing to do with that, it's the underlying privilege model that permits it. There's a good case to be made for using better languages than C and C++ for large classes of software. Don't weaken it by making absurd claims.

encryptluks2 4y ago

deleted 4y ago
[deleted]
potta_coffee 4y ago
I've never given Rust a chance because I'm utterly repulsed by the community.
- encryptluks2 4y ago
  I actually am quite please with it, or at least the programs I've used written in Rust... but the community has been pretty toxic and it hasn't been without its share of security vulnerabilities.

epistasis 4y ago

I think a better analogy may be nuclear power, than asbestos, because of the labor side of the tech. Using nuclear power correctly takes a ton of engineering prowess, lots of additional construction. If done well, it works great. When it goes bad, it goes really bad. So if it's 1982, maybe nuclear power or C is a good option. If it's 2022, new technology may provide a cheaper way of getting to the same end point, with less engineering and construction, and probably even less cost.

deleted 4y ago
[deleted]
adgjlsfhk1 4y ago
This is a worse analogy because good nuclear plants exist. With C, I've yet to see a widely used library written by multiple humans in C that doesn't have critical memory bugs.
- fxtentacle 4y ago
  Linux comes pretty close for practical usage. Or sqlite.
  - adgjlsfhk1 4y ago
    https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 https://www.cvedetails.com/product/47/Linux-Linux-Kernel.htm... and https://www.cvedetails.com/vulnerability-list.php?vendor_id=33&product_id=47&version_id=&page=1&hasexp=0&opdos=0&opec=0&opov=1&opcsrf=0&opgpriv=0&opsqli=0&opxss=0&opdirt=0&opmemc=0&ophttprs=0&opbyp=0&opfileinc=0&opginf=0&cvssscoremin=0&cvssscoremax=0&year=2022&month=0&cweid=0&order=3&trc=25&sha=0c6bafc0d41433be31a10f04664962b64905ce4f https://www.cvedetails.com/vulnerability-list.php?vendor_id=.... Linux has new security vulnerabilities found every year due to memory issues caused by C.
- Schroedingersat 4y ago
  Those C code bases all get used and many have lives depending on them. Generally the really bad disasters are almost always narrowly avoided before they come to public attention. Why would your experience there make you think the good nuclear plants are any different?

tomp 4y ago

> Safer alternatives exist. Do they? The only “safe” comparable alternative is unsafe Rust which as the name suggests isn’t actually safe.

jesse__ 4y ago
You're right. Alternatives that tick all the boxes that C does, and are also safer, do not exist. This guy is just doing the typical religious yelling about people doing their jobs (writing kernels, drivers, browsers, games, etc) with the most flexible tool for programming we've developed to date. Maybe one day Rust will become dominant. Maybe someone will overhaul the aliasing rules of C, write some similar lifetime tracking tooling, and it will live on for another 50 years. Who knows. The reason people still use C and C++ isn't because they're good languages (or even that people like them, as the comment states), it's that until recently there have been very few viable alternatives, and for some domains literally none at all. They've largely been the only option for a long time.
- notriddle 4y ago
  The article is about Ada SPARK, and nVidia using it to develop their firmware today.
  - jesse__ 4y ago
    Yes, I wasn't referring to the article, I was referring to the person comparing C to asbestos. It makes sense for nVidia to trade development time and prefer a language with formal verification for their firmware.
nordsieck 4y ago
> The only “safe” comparable alternative is unsafe Rust which as the name suggests isn’t actually safe. And for some applications, Rust isn't even an alternative. Not every chip is supported by LLVM.
Gigachad 4y ago
You typically don't have to write any unsafe Rust as an end user. The unsafe stuff is contained in very small and very rigorously analyzed standard library types. Which then provides you a safe interface to do all the stuff you normally do.

nordsieck 4y ago

> For whatever reason with C there’s this huge emotional component to it. Safer alternatives exist. For a lot of things, I just don't think this is true. For example, here is sqlite's reasoning for choosing C: https://www.sqlite.org/whyc.html https://www.sqlite.org/whyc.html I can't say I can really disagree with it.

wizofaus 4y ago
That article wins the argument for me, and I'm not a fan of C particularly. Admittedly it doesn't address security concerns, but the fact they're able to achieve 100% machine code level branch coverage (I wonder if that includes the possibility of executing injected code...) should go a long way towards generating confidence that there are no readily exploitable vulnerabilities.

spamizbad 4y ago

There are many C developers out there who will insist they have gained enough experience to never write code vulnerable to various memory safety exploits. Real "I actually drive safer slightly buzzed" vibes.

wiseowise 4y ago
> Real "I actually drive safer slightly buzzed" vibes. “I don’t need seatbelts, I actually know how to drive unlike others”
- abudabi123 4y ago
  phase out C on the schedule the internal combustion engine is going out of circulation as is being required

marcosdumay 4y ago

People also had a large and unexplainable emotional attachment to asbestos.

noobermin 4y ago

So it's not everything but as long as operating systems are written in C, it will be the language of choice for many projects.

kazinator 4y ago

We use all sorts of hazardous materials, which are safe if properly used, transported and stored. C is not "unsafe" in the sense that little bits of it break off in installations and make people sick, but in the sense that the assurance of safety almost all rests on the programmer. If code is safe, and not changed, it stays that way.

optymizer 4y ago

> It was fine at what it did No need to talk in past tense. C is still the best language at what it is meant for: writing fast software. Not safe software, _fast and portable_ software. > but the safety problems outweigh them Safety is to speed what security is to convenience. Frankly, most of the arguments I see today are just fear mongering. In my experience, there is no protecting users from developer mistakes that lead to software exploitation and 'unsafety', independent of the language being used. Memory issues are a common avenue, but if you take it away, the next issue will become the main avenue for exploitation, and you'll be back in the same spot, with the next generation of developers fearing that the new software safety level is insufficient to reach some ideal safety level, all while having traded off real world speed across the board to reach that point. > no new installations use it I'm writing a tool in C. It doesn't need to be perfectly secure. It does need to be fast. By using C we acknowledge that users want speed, more than they want safety, and that's our developer reality. That doesn't mean users don't want safety, it just means that outside of specialized domains, on average speed takes priority - people have been voting for decades that they want speed more than safety, and the process of deciding the priority is as you'd expect: users use money to buy a faster product and companies selling software invest in making their software fast first. The security argument is also weak. The whole point of cracking software is to find flaws in existing systems, regardless of the language they were coded in. One thing will always be true: anything that sends data can be cracked. You can only make the entry bar harder, but you will not create a language that is significantly safer and as fast as C because the optimizations that make software fast (like not checking array lengths, not checking for overflow, etc) are also the ones making it less secure. One can create a language that's safer than C and fast (in specific situations), but there will always be people cracking the core of whatever the 'safe' language du jour is, so you will have decreased security incidents on average, but have not eliminated them, while leaving room for a competitor to swoop in with a faster product that's safe enough, and it's your users who will decide who wins, not you. Just to emphasize this, so far, I have not seen any indication that the general population will shift to picking safety over speed, so you'd be betting against your users.

c-cube 4y ago
At this point there isn't strong evidence that C is going to deliver better performance than C++ or Rust, especially for a given amount of work. One could argue that better code reuse (templates, generics, crates, etc.) allow programmers to write faster code in C++ or rust. For example you need barely any work to use a really good hash table in rust, one that's really tricky to rewrite by hand because it involves simd and whatnot.

googlryas 4y ago

To adjust your analogy a little, we actually still use asbestos, but it just isn't used for the general public. It still has unique properties that are industrially or commercially useful, such as certain asphaltic roofing compounds and friction products like brake pads. But, it isn't used in products designed for the general public where strict oversight can't generally be provided.

ethbr0 4y ago
This is the key point that's often missed: asbestos isn't used anymoee in applications where the risks outweigh the benefits. We use incredibly dangerous materials in photolithography, nuclear weapons production, armor piercing projectiles, and aerospace... because there are no alternatives and/or the benefits outweigh the risks. What changed is that we learned more about asbestos (it causes cancer) and phased it out of applications where alternatives existed, even more expensive ones. In the C analogy, there may be places C continues to make sense... but it shouldn't be used anymore out of default, because it's the way things have always been done, or any other reason that doesn't end with "... and that's more important than an increased risk of security vulnerabilities."

hackerbrother 4y ago

More asbestos! More asbestos!

paulmd 4y ago
https://www.dailymail.co.uk/news/article-3091148/Chilling-image-shows-miners-playing-asbestos-shovelling-competition.html https://www.dailymail.co.uk/news/article-3091148/Chilling-im...

ploxiln 4y ago

C in software stacks is more like flame in kitchens. Fire is dangerous and bad for your health. Kitchen fires kill people, gas leaks kill people. It's possible to do without. But billions of people around the world cook with flame and do OK. All our ancestors did, and here we are. There will always be professional kitchens that use gas/flame (almost all of them). And it'll always be possible for your food to catch on fire anyway, if you cook it wrong. Unlike asbestos insulation in houses, or flame in your personal kitchen, you actually can't avoid C in your software stack. Do you use Linux, FreeBSD, or OpenBSD, or macOS, or Windows? Do you use Postgres or MySql or sqlite, or maybe redis or memcached? How about a language like Python or JS or Java or Ruby or Lua? Do you use rust? guess what the business-end of that compiler is written in! so you dabble at the tippy-top of the stack in some language like rust or go, so what?

ClumsyPilot 4y ago
> Unlike asbestos insulation in houses, you actually can't avoid C in your software stack You know what, construction industry could have made the same argument - oh look, all insulation suppliers use asbestos, the factory is built out of it too, its everywhere in the supply chain, you can't actually avoid asbestos if you ate trying to build a house, so we should learn to live with it. You can't avoid fossil fuels, you gave to use fossil fuels to produce a solar panel, so dreaming about clean energy is pointless. The difference is that some i industries pull the finger out of their bum and clean up their act, and some i dustries, like our's, does not. Even thoigh perfectly serviceable alternatives exist.

jstimpfle 4y ago

Depression can be bad, too. Maybe it can lead to cancer, and it undisputedly causes deaths. Other languages make me depressive and steal my focus. They make me go to great lengths trying to get the simplest things done. In C, it's like memset(p, 0, sizeof *p), done. Other languages make it such that I always code on 3 layers of abstraction to not have to do the "hard" task, but now I don't know the implementation of those layers. They make it such that I'm constantly torn to come up with an even more clever thing to say the same things, with even more abstractions and moving parts. They pull so much attention to themselves, distracting from the task that I want get done. With C, this is not the case. Maybe with a different personality, I could be similarly or even more productive in Rust, ignoring all the kitsch in its ecosystem. But I've started reading Rust projects dozens of times and have always turned away. They always use one more abstraction than I can be arsed to look up, always hide the most interesting and motivating parts behind a crate dependency. This is not the case with C, where it is easy to find good (enough) code that is honest and direct, and rewarding. I know that C is not perfect. We're having an open relationship, and I don't have any attachments (besides knowing it well) that prevent me from jumping ship when I find a better one.

qualudeheart 4y ago

MISRA C avoids those security flaws in a big way.

TazeTSchnitzel 4y ago
I wish that were true. It imposes a lot of restrictions but doesn't solve the fundamental issues of C.

raxxorraxor 4y ago

I have no emotion towards C. It is an old language and certainly an imperfect one. The thing is you just need to come up with something better. Maybe someday that can be Rust or another language. But you need something to replace it. This will not be a quick change. C is interoperable, and the industry is moving slowly.

mbrodersen 4y ago

There is a lot of software out there written in C. All of which needs maintenance. At work new C code gets checked in every day for software that runs major companies around the world. Having said that, I would never recommend C as the language of choice for new projects.