4 ms·

https://stackoverflow.com/questions/21177436/is-there-a-published-language-format-standard-for-rust-yet https://stackoverflow.com/questions/21177436/is-there-a-

by gens 6y ago

https://stackoverflow.com/questions/21177436/is-there-a-published-language-format-standard-for-rust-yet https://stackoverflow.com/questions/21177436/is-there-a-publ... 6 years ago. I was going to compare how many pages the rust standard has, and compare it to the C standard (plus 20% for the "correctly manage memory" that you pointed out as something extremely complicated). http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Anyway.. C is a rather simple language. No matter what the opinion of rust programmers is. Please don't respond to this post. At least not with the bog standard "undefined" "unsafe/memory" and other shallow conceptions.

bsder 6y ago
> plus 20% for the "correctly manage memory" Sorry. "correctly manage memory" in C is not 20% more problematic, it's like dividing by 0, infinity% more problematic. Nobody has gotten it right. Ever. Nobody. The Mozilla team switched from C to C++ trying to get memory right. Failed. Then they tried GC. Failed. Then they tried to go back to manual. Sill failed. So they wrote their own language to solve the problem--Rust. Jury is still out, but the situation is a lot better than when Mozilla started.
- xppq 6y ago
  So the Linux or BSD kernels, which the "systems language" Rust necessarily runs on, have not gotten it right. It is good to hear this, since it affirms that Rust only thrives on hype and that I'm not missing out at all. EDIT: The Rust Strike Force is already downvoting. Webshit morons.
  - aw1621107 6y ago
    > which the "systems language" Rust necessarily runs on Strictly speaking, Rust does not need to run on a kernel. If anything, the Rust developers have explicitly steered the language to be suitable for bare-metal situations. > So the Linux or BSD kernels... have not gotten it right ...Because they haven't? Just look at the CVE databases. A cursory search gives: * https://www.cvedetails.com/cve/CVE-2018-6916/ https://www.cvedetails.com/cve/CVE-2018-6916/ - FreeBSD: Improper validation and a use-after-free * https://www.cvedetails.com/cve/CVE-2019-5606/ https://www.cvedetails.com/cve/CVE-2019-5606/ - FreeBSD: Incorrect signal handling leading to write after free * https://www.cvedetails.com/cve/CVE-2019-15919/ https://www.cvedetails.com/cve/CVE-2019-15919/ - Linux: Use-after-free * https://www.cvedetails.com/cve/CVE-2019-15292/ https://www.cvedetails.com/cve/CVE-2019-15292/ - Linux: Use-after-free * https://www.cvedetails.com/cve/CVE-2019-15504/ https://www.cvedetails.com/cve/CVE-2019-15504/ - Linux: Double free In addition, Microsoft has said that ~70% of their CVEs are memory safety issues [0], and have been for many years. So no, easily accessible memory safety in C is not a solved issue yet. There are various techniques and tools that can be used to reduce or eliminate memory errors, but they have not seen widespread adoption for one reason or another. [0]: https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
    - cpk10 6y ago
      That 70% CVE figure is misleading: C and C++ obviously have a far higher market share, especially in fundamental Internet applications and kernels. So they have a higher number of CVE reports. But let's examine Rust despite its low market share: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12083 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1208... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010299 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...
      - GolDDranks 6y ago
        Note that none of these CVEs is exploitable without the developer _also_ misusing the API or exposing the vulnerability to some data that the attacker can control. It's unclear whether these can be thought of as bona fide security holes.
      - bsder 6y ago
        You might not want to throw that stone from the glass house that is the C standard library or the C++ standard library. Both of those have had vicious holes (memcpy/memmove anyone? s/f/printf? I can go on and on ...) that STILL aren't fixed (at least most implementation now just pass memcpy to memmove and be done with it). And part of the reason why musl and glibc are incompatible is that they disagree on certain things that produce vulnerabilities.
        jfkebwjsbx 6y ago
        What are you even talking about? There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy(). I hope you realize those functions are some of the most fundamental in the ISO C standard, defined by dozens of major companies. I am pretty sure their engineers know what they are doing...?
        bsder 6y ago
- adev_ 6y ago
  > The Mozilla team switched from C to C++ trying to get memory right. Failed. Still Mozilla software, including Firefox, run at more than 80% in C++ and are fully usable right now. It is also the case of probably almost all the software you see on your own desktop right now... Most of them are C++. Meaning, all considered, your notion of "failed" is pretty relative and opiniated.
littlestymaar 6y ago
Do you know how old and widely used C was when it got its spec ? The work on ANSI C started in 1983, 11 years after C came out. And it took 6 years! to complete. If Rust is as sucesful as C was during its 11 first years, Rust will most likely get a formal spec eventually. But don't hold your breath because it's going to take a loooong time to get there.

by gens 6y ago

bsder 6y ago

> plus 20% for the "correctly manage memory" Sorry. "correctly manage memory" in C is not 20% more problematic, it's like dividing by 0, infinity% more problematic. Nobody has gotten it right. Ever. Nobody. The Mozilla team switched from C to C++ trying to get memory right. Failed. Then they tried GC. Failed. Then they tried to go back to manual. Sill failed. So they wrote their own language to solve the problem--Rust. Jury is still out, but the situation is a lot better than when Mozilla started.

xppq 6y ago
So the Linux or BSD kernels, which the "systems language" Rust necessarily runs on, have not gotten it right. It is good to hear this, since it affirms that Rust only thrives on hype and that I'm not missing out at all. EDIT: The Rust Strike Force is already downvoting. Webshit morons.
- aw1621107 6y ago
  > which the "systems language" Rust necessarily runs on Strictly speaking, Rust does not need to run on a kernel. If anything, the Rust developers have explicitly steered the language to be suitable for bare-metal situations. > So the Linux or BSD kernels... have not gotten it right ...Because they haven't? Just look at the CVE databases. A cursory search gives: * https://www.cvedetails.com/cve/CVE-2018-6916/ https://www.cvedetails.com/cve/CVE-2018-6916/ - FreeBSD: Improper validation and a use-after-free * https://www.cvedetails.com/cve/CVE-2019-5606/ https://www.cvedetails.com/cve/CVE-2019-5606/ - FreeBSD: Incorrect signal handling leading to write after free * https://www.cvedetails.com/cve/CVE-2019-15919/ https://www.cvedetails.com/cve/CVE-2019-15919/ - Linux: Use-after-free * https://www.cvedetails.com/cve/CVE-2019-15292/ https://www.cvedetails.com/cve/CVE-2019-15292/ - Linux: Use-after-free * https://www.cvedetails.com/cve/CVE-2019-15504/ https://www.cvedetails.com/cve/CVE-2019-15504/ - Linux: Double free In addition, Microsoft has said that ~70% of their CVEs are memory safety issues [0], and have been for many years. So no, easily accessible memory safety in C is not a solved issue yet. There are various techniques and tools that can be used to reduce or eliminate memory errors, but they have not seen widespread adoption for one reason or another. [0]: https://msrc-blog.microsoft.com/2019/07/16/a-proactive-approach-to-more-secure-code/ https://msrc-blog.microsoft.com/2019/07/16/a-proactive-appro...
  - cpk10 6y ago
    That 70% CVE figure is misleading: C and C++ obviously have a far higher market share, especially in fundamental Internet applications and kernels. So they have a higher number of CVE reports. But let's examine Rust despite its low market share: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12083 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1208... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010299 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1010... https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000810 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000...
    - GolDDranks 6y ago
      Note that none of these CVEs is exploitable without the developer _also_ misusing the API or exposing the vulnerability to some data that the attacker can control. It's unclear whether these can be thought of as bona fide security holes.
    - bsder 6y ago
      You might not want to throw that stone from the glass house that is the C standard library or the C++ standard library. Both of those have had vicious holes (memcpy/memmove anyone? s/f/printf? I can go on and on ...) that STILL aren't fixed (at least most implementation now just pass memcpy to memmove and be done with it). And part of the reason why musl and glibc are incompatible is that they disagree on certain things that produce vulnerabilities.
      - jfkebwjsbx 6y ago
        What are you even talking about? There is nothing to fix in the functions you mentioned, and no sane implementation calls memmove() from memcpy(). I hope you realize those functions are some of the most fundamental in the ISO C standard, defined by dozens of major companies. I am pretty sure their engineers know what they are doing...?
        bsder 6y ago
adev_ 6y ago
> The Mozilla team switched from C to C++ trying to get memory right. Failed. Still Mozilla software, including Firefox, run at more than 80% in C++ and are fully usable right now. It is also the case of probably almost all the software you see on your own desktop right now... Most of them are C++. Meaning, all considered, your notion of "failed" is pretty relative and opiniated.

littlestymaar 6y ago

Do you know how old and widely used C was when it got its spec ? The work on ANSI C started in 1983, 11 years after C came out. And it took 6 years! to complete. If Rust is as sucesful as C was during its 11 first years, Rust will most likely get a formal spec eventually. But don't hold your breath because it's going to take a loooong time to get there.