6 ms·

I never understood the use of D, or any of the "C replacements" languages trends. C does work pretty well, but it's like a sharp tool. Use with a lot of care wi

I never understood the use of D, or any of the "C replacements" languages trends. C does work pretty well, but it's like a sharp tool. Use with a lot of care with your remaining fingers. There are a LOT of things C is blamed for, and languages try to introduce complicated syntaxes and abstraction to prevent them from happening, however, most of these other languages are ALSO open to the same security issues (or sometime, more), just on a different level. Perhaps they look a lot safer because they haven't had the same level of scrutiny as good old C. In the meantime they introduce a 'duh/WTF' effect when you try to bring someone else in on the codebase. C with good static analyser coverage (cppcheck, clang 'scan-build', smatch[0]) and reasonable discipline is pretty easy to maintain, VERY easy to debug, extraordinarily low footprint and very fast, so taking the time and having a BIT of discipline to harness that power is well worth it. As the article mentions, I'm one of the guys who did 20 years of C++ before 'reverting back' to C, and I'd LOVE a few of the things I've had to give up -- however, a new language is not really something I need. [0]: http://smatch.sourceforge.net http://smatch.sourceforge.net

AgentME 7y ago
>most of these other languages are ALSO open to the same security issues How often do programs in non-C/C++ languages get remote code execution vulnerabilities? I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++. Sure, it occasionally happens in other languages, but practically only when someone does something like misuse one of a specific set of APIs that allow code loading. In C/C++, any code that slightly fucks up writing to an array or passes a pointer to previously-freed memory around can cause a RCE vulnerability that lets an attacker literally run code on your system and take it over. Inspecting a C/C++ codebase made by a junior person for vulnerabilities is a total nightmare. Inspecting a codebase in any other language for RCE vulnerabilities generally means you grep for a couple APIs and look at how they get used.
- buserror 7y ago
  I don't believe that, you mention this because you put 100% trust on the runtime. When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime. So Sure, RIGHT NOW the runtime might be safe from scrutiny, but is it because its SAFE or just not as such a high profile, just yet? On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.
  - klez 7y ago
    The difference is that if the bug is in the runtime you have to fix one place and everyone downstream gets that. If you solve one such bug in curl, you solved it just in curl. EDIT: I thought about it a bit more and realized it cuts both ways. If you have an RCE in a standard library a lot of programs get an RCE for free while it's not patched. So yeah, a bit of a mixed bag.
    - ppseafield 7y ago
      There's also the difference that, in a GC'd language, you don't have both the language authors and the language users both competing to put these kinds of bugs in their software. :)
      - tomatocracy 7y ago
        True, but when you want to interface between code written in two different GC'd languages then you can get similar problems if you're not careful. As the number and use of these various next generation languages proliferates, I suspect we might start to see more of that kind of thing appearing over time.
    - oconnor663 7y ago
      I posted a bit more beside this comment, but I think the difference isn't so much updates or code review but rather the design intention of the language. A language like Java or Python or Rust is designed for every operation to produce some defined behavior, and you can't generally trigger RCE unless you call some function like `unsafePerilousDangerZone(heinousRawPtr)`. Those design defaults bubbles up through libraries written in those languages, so that when you use other people's code and make a mistake, the result is either a crash or an unfortunate-but-at-least-well-defined logic bug. The opposite is true in C and C++, and that bubbles up through the libraries in those languages too.
    - CaptainMarvel 7y ago
      [[Off-Topic - Sorry!]] Hi Klez, I determined this to be the only way to get in touch regarding a previous discussion we had on Blendle [0] as I can no longer reply on that thread. This was back in 2017 so they may have fixed their issues. Alexander Klöpping <alexander.klopping@blendle.com> emailed me, I'll grant it was a generic welcome email, asking for feedback. I took the opportunity to email back informing him of the problems with using my email address [1]. I don't recall the problem now, but it seems they accepted my email address but then later rejected it during the sign-up process (as I clearly received an email correctly...). I no longer have their response, but from memory, it was a different customer service person, and they rejected the idea that they had any problem AND/OR explicitly said they weren't going to make any changes. Oh, and they sent that response to the email that I explicitly said wouldn't work (it automatically gets sent to the trash to be deleted which is also why I don't have it any more). Their rejection of fixing their service is what made me decide to put Blendle in the trash category. [0]: https://news.ycombinator.com/item?id=20138213 https://news.ycombinator.com/item?id=20138213 [1]: My email, sent from X+Y@gmail.com Dear Alexander Klöpping, When I first heard about Blendle I was excited at the concept of being able to read high-quality journalism from multiple different sources through one - ad-free - platform and one reasonably-priced payment system, and so I signed up for the beta. I successfully started the process of joining Blendle by unlocking and selecting some preferences. However, I have been unable to proceed past entering my email address, X+Y@gmail.com. I should make it clear that the email address X@gmail.com cannot be used. Could you please assist me and help me get started with Blendle? Best, [redacted]
- pantalaimon 7y ago
  > I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++. Maybe that's because most software is written in C/C++?
  - azernik 7y ago
    Compared to Java, Javascript, Python, put together?
    - adev_ 7y ago
      > Compared to Java, Javascript, Python, put together? Yes still. Look to your laptop right now and count the software running in C/C++ vs anything else. They still dominate by far. And the current fashion of writing everything in Javascript + Electron/NodeJS, just made the C/C++ backend more important than ever. NodeJS is in C/C++, V8 is in C++, Chromium is in C++, Firefox is in C++/Rust and every library behind are in C.
      - pjmlp 7y ago
        So lets us constrain to the Linux kernel, with its patch review process, ksan and static analysis tooling. As per Google talk at Linux Kernel Summit 2018, 68% of Linux kernel exploits are caused by C's lack of safety against memory corruption, in spite of all the tools and processes they have in place. Hence, the Kernel Self Protection Project sponsored by Google. https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
  - AgentME 7y ago
    Even if you corrected for that, I would still expect this to be true. A potential RCE in C/C++ is literally as easy as writing past the end of an array or writing to a pointer to something that's already been freed. Few other languages give such huge consequences to minor mistakes in average code. The arguments that C/C++ are just as safe as other languages and that's it's just a matter of opinion or experience are unfounded. It's like saying a minefield is just as safe as anywhere else to walk because you can randomly suddenly die anywhere else too because of stuff like strokes or heart attacks. You just gotta have good landmine senses and it's your own fault if you can't avoid them.
- jcelerier 7y ago
  > I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++. This is where it is critical to differenciate C and C++. https://jaxenter.com/security-vulnerabilities-languages-157038.html https://jaxenter.com/security-vulnerabilities-languages-1570... > Total reported open source vulnerabilities per language: > C (46.9%) > PHP (16.7%) > Java (11.4%) > JavaScript (10.2%) > Python (5.45%) > C++ (5.23%) > Ruby (4.25%)
  - Asooka 7y ago
    I would like to see those stats divided by total SLOC in all projects for each language. C might top the list simply because there's a lot of C projects in the dataset.
    - pjmlp 7y ago
      Well, Morris Worm is now 30 years old and C CVEs due to memory corruption bugs have kept a stendy growth since then.
edwintorok 7y ago
Improvements in tooling like address sanitizer, valgrind, afl also help a lot in improving code quality, especially if you make them part of your CI. However it should possible to have a language that gives you both the speed and safety guarantees. There are many languages that contend for that category: Go (not on speed though), Rust, etc. Might be worth looking at some of the Rust projects like ripgrep that are really focused on performance and faster than C implementations like grep.
- DeathArrow 7y ago
  Go would never replace C because of speed and lack of direct memory access. Rust syntax is very ugly, Rust is more complex than C and harder to read. is very simple.
  - pjmlp 7y ago
    Go can do the same direct memory access as C does via unsafe.Pointer. If you mean real hardware access, not even C can do that unless it is running bare metal without an underlying OS or MMU controlling the access, both situation outside of ISO C specification.
    - makapuf 7y ago
      I wouldn't say baremetal is more outside of spec than MMU/ OS virtual memory is outside of spec.
apta 7y ago
> C does work pretty well The GCC team thinks differently, since GCC moved to C++ [1] [1] https://lwn.net/Articles/542457/ https://lwn.net/Articles/542457/
WalterBright 7y ago
> C does work pretty well Consider C's Biggest Mistake: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html You can use D in -betterC mode, write code pretty much just like you would in C, and not have that problem.
- x0re4x 7y ago
  > Consider C's Biggest Mistake I do not think it is a significant problem in C. It might be more of a problem in C++. > You can use D in -betterC mode, write code pretty much just like you would in C, and not have that problem. D is an improved, more polished version of _C++_, not C; "-betterC" mode is misleading, it is more of a "betterC++" mode (features: classes, exceptions, RAII, templates). "The simplicity of C is more useful than the additional features of C++." -- (Sam Watkins) s/C++/D/g Don't get me wrong: D would be a great replacement for _C++_, but not C. For a better C I would look at a subset of Go (GC would have to go away).
  - WalterBright 7y ago
    D in "betterC" mode does not have GC, classes, exceptions, or RTTI. Nor does it need the D (or C) runtime library. (It does have RAII without using exceptions.)
    - x0re4x 7y ago
      Thank you for clarification. I was looking at https://www.digitalmars.com/articles/betterC.html https://www.digitalmars.com/articles/betterC.html, https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html is a better description.
rramadass 7y ago
Amen, brother! But i would add C++ too (with reservations on the "easy" part); to me they go together. In one of my previous posts i had mentioned the advantages of C, two of which are worth listing here. a) C allows you to program "everything"; from big honking servers (backend and frontend), networking protocols and systems etc. and all the way down to itty-bitty 8-bit MCUs. Basically from above assembly to any sort of application you might care about. b) C is the de-facto "glue" language to everything i.e. the "assembly" of high-level languages. Almost all languages allow you to link to a C module. I am often mystified when people say C is "hard" when they program in languages like Java/Python/Javascript etc. To me these languages are baroque and hard since they require more mental effort to memorize and use the bazillion frameworks, libraries, objects and methods. I find them all quite overwhelming.
- jcelerier 7y ago
  > Almost all languages allow you to link to a C module. no, almost all languages allow you to call into your operating system's native dynamic library format. That this binary was originally built with C, C++ in extern "C", fortran, ADA, D -betterC, Pascal... does not matter at all. C just happens to be the most popular language for building those...
  - rramadass 7y ago
    >That this binary was originally built with C, C++ in extern "C", fortran, ADA, D -betterC, Pascal... does not matter at all. Not quite; the point of using the phrase "link to a C module" was to point out that all of them conform to the applicable "C ABI" for a platform and therein lies C's strength as a "glue" language.
    - jcelerier 7y ago
      C does not have an ABI in itself, it just uses the conventions of its host system. e.g. how function calls are done, how names are mangled (for instance on macOS all function names are prepended with an underscore and not on 64-bit windows nor linux...), etc... none of this is defined in the C standard, and it varies across platforms.

AgentME 7y ago

>most of these other languages are ALSO open to the same security issues How often do programs in non-C/C++ languages get remote code execution vulnerabilities? I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++. Sure, it occasionally happens in other languages, but practically only when someone does something like misuse one of a specific set of APIs that allow code loading. In C/C++, any code that slightly fucks up writing to an array or passes a pointer to previously-freed memory around can cause a RCE vulnerability that lets an attacker literally run code on your system and take it over. Inspecting a C/C++ codebase made by a junior person for vulnerabilities is a total nightmare. Inspecting a codebase in any other language for RCE vulnerabilities generally means you grep for a couple APIs and look at how they get used.

buserror 7y ago
I don't believe that, you mention this because you put 100% trust on the runtime. When I see syntax like: var array=something[4...$] I don't see security there, all I see is someone pushing the problem further under the carpet, into the runtime. So Sure, RIGHT NOW the runtime might be safe from scrutiny, but is it because its SAFE or just not as such a high profile, just yet? On the other hand I DO agree that 'junior' programming will always be a problem, regardless of the matter, and pretty much, regardless of the language.
- klez 7y ago
  The difference is that if the bug is in the runtime you have to fix one place and everyone downstream gets that. If you solve one such bug in curl, you solved it just in curl. EDIT: I thought about it a bit more and realized it cuts both ways. If you have an RCE in a standard library a lot of programs get an RCE for free while it's not patched. So yeah, a bit of a mixed bag.
  - ppseafield 7y ago
    There's also the difference that, in a GC'd language, you don't have both the language authors and the language users both competing to put these kinds of bugs in their software. :)
    - tomatocracy 7y ago
      True, but when you want to interface between code written in two different GC'd languages then you can get similar problems if you're not careful. As the number and use of these various next generation languages proliferates, I suspect we might start to see more of that kind of thing appearing over time.
  - oconnor663 7y ago
    I posted a bit more beside this comment, but I think the difference isn't so much updates or code review but rather the design intention of the language. A language like Java or Python or Rust is designed for every operation to produce some defined behavior, and you can't generally trigger RCE unless you call some function like `unsafePerilousDangerZone(heinousRawPtr)`. Those design defaults bubbles up through libraries written in those languages, so that when you use other people's code and make a mistake, the result is either a crash or an unfortunate-but-at-least-well-defined logic bug. The opposite is true in C and C++, and that bubbles up through the libraries in those languages too.
  - CaptainMarvel 7y ago
    [[Off-Topic - Sorry!]] Hi Klez, I determined this to be the only way to get in touch regarding a previous discussion we had on Blendle [0] as I can no longer reply on that thread. This was back in 2017 so they may have fixed their issues. Alexander Klöpping <alexander.klopping@blendle.com> emailed me, I'll grant it was a generic welcome email, asking for feedback. I took the opportunity to email back informing him of the problems with using my email address [1]. I don't recall the problem now, but it seems they accepted my email address but then later rejected it during the sign-up process (as I clearly received an email correctly...). I no longer have their response, but from memory, it was a different customer service person, and they rejected the idea that they had any problem AND/OR explicitly said they weren't going to make any changes. Oh, and they sent that response to the email that I explicitly said wouldn't work (it automatically gets sent to the trash to be deleted which is also why I don't have it any more). Their rejection of fixing their service is what made me decide to put Blendle in the trash category. [0]: https://news.ycombinator.com/item?id=20138213 https://news.ycombinator.com/item?id=20138213 [1]: My email, sent from X+Y@gmail.com Dear Alexander Klöpping, When I first heard about Blendle I was excited at the concept of being able to read high-quality journalism from multiple different sources through one - ad-free - platform and one reasonably-priced payment system, and so I signed up for the beta. I successfully started the process of joining Blendle by unlocking and selecting some preferences. However, I have been unable to proceed past entering my email address, X+Y@gmail.com. I should make it clear that the email address X@gmail.com cannot be used. Could you please assist me and help me get started with Blendle? Best, [redacted]
pantalaimon 7y ago
> I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++. Maybe that's because most software is written in C/C++?
- azernik 7y ago
  Compared to Java, Javascript, Python, put together?
  - adev_ 7y ago
    > Compared to Java, Javascript, Python, put together? Yes still. Look to your laptop right now and count the software running in C/C++ vs anything else. They still dominate by far. And the current fashion of writing everything in Javascript + Electron/NodeJS, just made the C/C++ backend more important than ever. NodeJS is in C/C++, V8 is in C++, Chromium is in C++, Firefox is in C++/Rust and every library behind are in C.
    - pjmlp 7y ago
      So lets us constrain to the Linux kernel, with its patch review process, ksan and static analysis tooling. As per Google talk at Linux Kernel Summit 2018, 68% of Linux kernel exploits are caused by C's lack of safety against memory corruption, in spite of all the tools and processes they have in place. Hence, the Kernel Self Protection Project sponsored by Google. https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Pr...
- AgentME 7y ago
  Even if you corrected for that, I would still expect this to be true. A potential RCE in C/C++ is literally as easy as writing past the end of an array or writing to a pointer to something that's already been freed. Few other languages give such huge consequences to minor mistakes in average code. The arguments that C/C++ are just as safe as other languages and that's it's just a matter of opinion or experience are unfounded. It's like saying a minefield is just as safe as anywhere else to walk because you can randomly suddenly die anywhere else too because of stuff like strokes or heart attacks. You just gotta have good landmine senses and it's your own fault if you can't avoid them.
jcelerier 7y ago
> I'm sure the CVE numbers will overwhelmingly show that most RCE-capable vulnerabilities are in C/C++. This is where it is critical to differenciate C and C++. https://jaxenter.com/security-vulnerabilities-languages-157038.html https://jaxenter.com/security-vulnerabilities-languages-1570... > Total reported open source vulnerabilities per language: > C (46.9%) > PHP (16.7%) > Java (11.4%) > JavaScript (10.2%) > Python (5.45%) > C++ (5.23%) > Ruby (4.25%)
- Asooka 7y ago
  I would like to see those stats divided by total SLOC in all projects for each language. C might top the list simply because there's a lot of C projects in the dataset.
  - pjmlp 7y ago
    Well, Morris Worm is now 30 years old and C CVEs due to memory corruption bugs have kept a stendy growth since then.

edwintorok 7y ago

Improvements in tooling like address sanitizer, valgrind, afl also help a lot in improving code quality, especially if you make them part of your CI. However it should possible to have a language that gives you both the speed and safety guarantees. There are many languages that contend for that category: Go (not on speed though), Rust, etc. Might be worth looking at some of the Rust projects like ripgrep that are really focused on performance and faster than C implementations like grep.

DeathArrow 7y ago
Go would never replace C because of speed and lack of direct memory access. Rust syntax is very ugly, Rust is more complex than C and harder to read. is very simple.
- pjmlp 7y ago
  Go can do the same direct memory access as C does via unsafe.Pointer. If you mean real hardware access, not even C can do that unless it is running bare metal without an underlying OS or MMU controlling the access, both situation outside of ISO C specification.
  - makapuf 7y ago
    I wouldn't say baremetal is more outside of spec than MMU/ OS virtual memory is outside of spec.

apta 7y ago

> C does work pretty well The GCC team thinks differently, since GCC moved to C++ [1] [1] https://lwn.net/Articles/542457/ https://lwn.net/Articles/542457/

WalterBright 7y ago

> C does work pretty well Consider C's Biggest Mistake: https://www.digitalmars.com/articles/b44.html https://www.digitalmars.com/articles/b44.html You can use D in -betterC mode, write code pretty much just like you would in C, and not have that problem.

x0re4x 7y ago
> Consider C's Biggest Mistake I do not think it is a significant problem in C. It might be more of a problem in C++. > You can use D in -betterC mode, write code pretty much just like you would in C, and not have that problem. D is an improved, more polished version of _C++_, not C; "-betterC" mode is misleading, it is more of a "betterC++" mode (features: classes, exceptions, RAII, templates). "The simplicity of C is more useful than the additional features of C++." -- (Sam Watkins) s/C++/D/g Don't get me wrong: D would be a great replacement for _C++_, but not C. For a better C I would look at a subset of Go (GC would have to go away).
- WalterBright 7y ago
  D in "betterC" mode does not have GC, classes, exceptions, or RTTI. Nor does it need the D (or C) runtime library. (It does have RAII without using exceptions.)
  - x0re4x 7y ago
    Thank you for clarification. I was looking at https://www.digitalmars.com/articles/betterC.html https://www.digitalmars.com/articles/betterC.html, https://dlang.org/spec/betterc.html https://dlang.org/spec/betterc.html is a better description.

rramadass 7y ago

Amen, brother! But i would add C++ too (with reservations on the "easy" part); to me they go together. In one of my previous posts i had mentioned the advantages of C, two of which are worth listing here. a) C allows you to program "everything"; from big honking servers (backend and frontend), networking protocols and systems etc. and all the way down to itty-bitty 8-bit MCUs. Basically from above assembly to any sort of application you might care about. b) C is the de-facto "glue" language to everything i.e. the "assembly" of high-level languages. Almost all languages allow you to link to a C module. I am often mystified when people say C is "hard" when they program in languages like Java/Python/Javascript etc. To me these languages are baroque and hard since they require more mental effort to memorize and use the bazillion frameworks, libraries, objects and methods. I find them all quite overwhelming.

jcelerier 7y ago
> Almost all languages allow you to link to a C module. no, almost all languages allow you to call into your operating system's native dynamic library format. That this binary was originally built with C, C++ in extern "C", fortran, ADA, D -betterC, Pascal... does not matter at all. C just happens to be the most popular language for building those...
- rramadass 7y ago
  >That this binary was originally built with C, C++ in extern "C", fortran, ADA, D -betterC, Pascal... does not matter at all. Not quite; the point of using the phrase "link to a C module" was to point out that all of them conform to the applicable "C ABI" for a platform and therein lies C's strength as a "glue" language.
  - jcelerier 7y ago
    C does not have an ABI in itself, it just uses the conventions of its host system. e.g. how function calls are done, how names are mangled (for instance on macOS all function names are prepended with an underscore and not on 64-bit windows nor linux...), etc... none of this is defined in the C standard, and it varies across platforms.