5 ms·

> So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. If the desire is -- you would like to create

> So I hope there would be a way for me to justify using C, along with a plan to minimize memory vulnerabilities. If the desire is -- you would like to create new software in C because you like C, I think that presents some really difficult questions in this framework, simply because a reasonable alternative exists. First, I think you have to ask: What kind of programs at you writing? Are they FOSS? Do you sell them? Are they likely to cause "damages"? If what you are doing is writing software for the joy of writing software, I'm not sure you have much to worry about. If you're writing a bank transaction server, exposed to untrusted inputs, in C and you're selling this software, you might have something to worry about, because there exists a reasonable alternative in Rust.

gavinhoward 3y ago
They are FOSS, but they are for a business, so yes, I will be affected. Rust is unfortunately not a reasonable alternative in some cases. As an example, my software needs just a C compiler to build itself. You can build my software completely with: tcc -run bootstrap/boostrap.c tcc This is because my software includes a build system meant to bootstrap other software. This use case is a good reason to avoid Rust. Another reason Rust may not be reasonable is the pervasiveness of async. Personally (not in general), async does not work for me. Rust is not the last word in programming languages. I am working on an alternative that will not only not have async, but will have more static analysis because destructors will be guaranteed to run. If you had read my post, you would know that I am planning to rewrite my stuff in that language as soon as possible. If Rust becomes required, I would be forced to stop work on that language, and progress would slow down. There are valid reasons to use C, even for software that handles untrusted inputs.
- mustache_kimono 3y ago
  > Rust is unfortunately not a reasonable alternative in some cases. Sure, and tort law is a flexible framework, so you will be allowed to make that argument. The only problem is if your software blows up in a way Rust was meant to prevent.
  - gavinhoward 3y ago
    If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. I am trying to hit the same level of robustness as those, and if their level is still not acceptable, our industry will implode. I get that it's not okay to have 70% of vulnerabilities be memory safety bugs, but C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less.
    - mustache_kimono 3y ago
      > If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. If your software blows up, in a way Rust would have prevented, and caused damages, isn't it kind of fair someone say "Hey maybe you shouldn't be using C"? My point was simply -- if your software is not in a place where damages occur, fine, who cares, write it in C. But if it is, and Rust exists, and could work just as well in that environment? And if you must still write in C, that's still fine, until you start selling software and causing your customers damages. > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. Why?
      - gavinhoward 3y ago
        > If your software blows up, in a way Rust would have prevented, and caused damages, isn't it kind of fair someone say "Hey maybe you shouldn't be using C"? No, that would not automatically be fair. It depends on context. > But if it is, and Rust exists, and could work just as well in that environment? But that's what I am saying: Rust won't work as well in that environment. My stretch goal is to have my build system replace the awful custom Makefile build for FreeBSD. In that context, Rust doesn't exist, even if they add it to the base system because something would have to build Rust and LLVM. Same reason my bc is in C: it is used to build the Linux kernel. Anyway, who defines if Rust works "just as well" in an environment? It all depends on context. You can't say that any Tier 1 and Tier 2 platform must use Rust for reasons such as the one I laid out above. And what if my language succeeds and has more bug smashing power than Rust? Should the directive immediately be, "If any Rust project causes damages that Yao could have prevented, that project owner is liable"? Of course not. > > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. > Why? Call it a hunch, but roughly, I think that a C project that reduces its memory bugs to that much would have fewer vulnerabilities than an equivalent Rust project, just because it would smash a lot of non-memory bugs along the way. That is the criteria that should be used: how many bugs does it have per KLoC, number of statements, cyclomatic complexity, whatever. Otherwise, you're just effectively mandating Rust anyway, and Rust projects could get away with murder. But set an objective criteria like that, and SQLite and Curl would survive, I would make my project hit it, and poorly done Rust projects would have to clean up their act. IOW, I do agree that Rust should be the default, but we shouldn't choose a metric that is clearly biased in its favor.

gavinhoward 3y ago

They are FOSS, but they are for a business, so yes, I will be affected. Rust is unfortunately not a reasonable alternative in some cases. As an example, my software needs just a C compiler to build itself. You can build my software completely with: tcc -run bootstrap/boostrap.c tcc This is because my software includes a build system meant to bootstrap other software. This use case is a good reason to avoid Rust. Another reason Rust may not be reasonable is the pervasiveness of async. Personally (not in general), async does not work for me. Rust is not the last word in programming languages. I am working on an alternative that will not only not have async, but will have more static analysis because destructors will be guaranteed to run. If you had read my post, you would know that I am planning to rewrite my stuff in that language as soon as possible. If Rust becomes required, I would be forced to stop work on that language, and progress would slow down. There are valid reasons to use C, even for software that handles untrusted inputs.

mustache_kimono 3y ago
> Rust is unfortunately not a reasonable alternative in some cases. Sure, and tort law is a flexible framework, so you will be allowed to make that argument. The only problem is if your software blows up in a way Rust was meant to prevent.
- gavinhoward 3y ago
  If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. I am trying to hit the same level of robustness as those, and if their level is still not acceptable, our industry will implode. I get that it's not okay to have 70% of vulnerabilities be memory safety bugs, but C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less.
  - mustache_kimono 3y ago
    > If every bug that Rust could have prevented is enough to allow people to sue me to oblivion, then SQLite and Curl will also have to be pulled from the market. If your software blows up, in a way Rust would have prevented, and caused damages, isn't it kind of fair someone say "Hey maybe you shouldn't be using C"? My point was simply -- if your software is not in a place where damages occur, fine, who cares, write it in C. But if it is, and Rust exists, and could work just as well in that environment? And if you must still write in C, that's still fine, until you start selling software and causing your customers damages. > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. Why?
    - gavinhoward 3y ago
      > If your software blows up, in a way Rust would have prevented, and caused damages, isn't it kind of fair someone say "Hey maybe you shouldn't be using C"? No, that would not automatically be fair. It depends on context. > But if it is, and Rust exists, and could work just as well in that environment? But that's what I am saying: Rust won't work as well in that environment. My stretch goal is to have my build system replace the awful custom Makefile build for FreeBSD. In that context, Rust doesn't exist, even if they add it to the base system because something would have to build Rust and LLVM. Same reason my bc is in C: it is used to build the Linux kernel. Anyway, who defines if Rust works "just as well" in an environment? It all depends on context. You can't say that any Tier 1 and Tier 2 platform must use Rust for reasons such as the one I laid out above. And what if my language succeeds and has more bug smashing power than Rust? Should the directive immediately be, "If any Rust project causes damages that Yao could have prevented, that project owner is liable"? Of course not. > > But C projects shouldn't have to be perfect on that front. Just close enough. Maybe 10% or less. > Why? Call it a hunch, but roughly, I think that a C project that reduces its memory bugs to that much would have fewer vulnerabilities than an equivalent Rust project, just because it would smash a lot of non-memory bugs along the way. That is the criteria that should be used: how many bugs does it have per KLoC, number of statements, cyclomatic complexity, whatever. Otherwise, you're just effectively mandating Rust anyway, and Rust projects could get away with murder. But set an objective criteria like that, and SQLite and Curl would survive, I would make my project hit it, and poorly done Rust projects would have to clean up their act. IOW, I do agree that Rust should be the default, but we shouldn't choose a metric that is clearly biased in its favor.