4 ms·

its a very messy language - its annoying to see that its the best extension to C. i constantly want something better than C - something where the compiler has

by jheriko 13y ago

its a very messy language - its annoying to see that its the best extension to C. i constantly want something better than C - something where the compiler has freedom to optimise my memory layout with a keyword for types that have to cross boundaries. something with metaprogramming built in. something where const is not just a promise, but the law etc...

jokoon 13y ago
then make it, and watch it fail Also "C is quirky, flawed, and an enormous success" Denis Ritchie.
- pjmlp 13y ago
  And the cause we have security exploits caused by bad pointers and arrays out of bounds.
  - jokoon 13y ago
    I don't know what to think of this comment. Does this mean we should not use C or C++ ? Security does not necessarily always matter when you're programming something, it does when you make widely used libraries or application or drivers or an OS, which are done by experts and tightly reviewed, so the language is not an issue. Sometime you'll need pure performance or very low power consumption, and there will be no concerns of security between there will absolutely no way to compromise it (no "vector"). Security is not a particular feature of any particular programming language anyways, every program, whatever the language, is subject to security concern, it's not a language concern.
    - pjmlp 13y ago
      > I don't know what to think of this comment. Does this mean we should not use C or C++ ? Yes. Although the insecure design of C and C++ (thanks to its C underpinnings) are just an attack vector from many possible ones, it is quite easy to get exploited thanks to the skills of many people writing applications on those languages. Removing away the possibility of out of bounds errors and pointer misuse, not possible in other safer systems programming languages, already removes away many of those attacks. So nowadays we have to deal with compiling with -Wall -Wpedatic -Werror, coupled with valgrind like tools and static analyzers to achieve some level of confidence that undefined behaviors and pointer misuses are not creeping in the code. You are right, this is only a small step in the whole security picture, there is also SQL injection, social engineering and many other forms of attacks. Still buffer overflow exploits remain one of the first forms of attack. I do code in C++ since the ARM days, so I do know it quite well. Not making this argument as an anti-C++ zealot.
      - jokoon 13y ago
        > Yes. > Although the insecure design of C and C++ (thanks to its C underpinnings) are just an attack vector from many possible ones, it is quite easy to get exploited thanks to the skills of many people writing applications on those languages. You can't have both performance AND remove the chances programmers will make mistakes. A tool is a tool with its compromises, you can't have all the advantages. > Removing away the possibility of out of bounds errors and pointer misuse, not possible in other safer systems programming languages, already removes away many of those attacks. Then don't use pointers, or learn how to use them properly. You should not hack into pointers anyway, there are never good reason to do so, both for risks of bugs and reduced code re-usability. STL containers make pointer use already quite almost irrelevant. And if it's only C, not C++, I'd argue that C is quite an old system language. Security is an expensive feature, and you're free to code faster without minding security if the business you're doing allows it. The better solution in all this, is using solutions like Cython, or make tools that allows easier bindings with C++ libraries. It doesn't change the fact that often, you'll need to optimize a part of your code, and you'll need to make a C/C++ library out of it, which you'll link against. All this process is quite not standard, and will cost time and learning, because it's quite painful. Security is often not worth the effort. Often it's much more easier to make sure users are using secure applications and securing your network and teaching users about security, than hire a security expert to review your code. And by the way, if someone hack into your system and steal stuff, it's still a criminal act, it's not the fault of the guy who decided to use C++ because he needed speed.
        pjmlp 13y ago
        > You can't have both performance AND remove the chances programmers will make mistakes. A tool is a tool with its compromises, you can't have all the advantages. Ada is a possible compromise. Modula-2 used to be one as well, before C got spread outside of UNIX. > And if it's only C, not C++, I'd argue that C is quite an old system language. Security is an expensive feature, and you're free to code faster without minding security if the business you're doing allows it. Yes, it is about C. C++ security flaws are a consequence of its C compatibility. Nowadays security is a must for everything except toy programs.
coldtea 13y ago
Well, Rust is your best bet for now, seeing that Go screwed it.
- pjmlp 13y ago
  Or D, Ada, SPARK

by jheriko 13y ago

jokoon 13y ago

then make it, and watch it fail Also "C is quirky, flawed, and an enormous success" Denis Ritchie.

pjmlp 13y ago
And the cause we have security exploits caused by bad pointers and arrays out of bounds.
- jokoon 13y ago
  I don't know what to think of this comment. Does this mean we should not use C or C++ ? Security does not necessarily always matter when you're programming something, it does when you make widely used libraries or application or drivers or an OS, which are done by experts and tightly reviewed, so the language is not an issue. Sometime you'll need pure performance or very low power consumption, and there will be no concerns of security between there will absolutely no way to compromise it (no "vector"). Security is not a particular feature of any particular programming language anyways, every program, whatever the language, is subject to security concern, it's not a language concern.
  - pjmlp 13y ago
    > I don't know what to think of this comment. Does this mean we should not use C or C++ ? Yes. Although the insecure design of C and C++ (thanks to its C underpinnings) are just an attack vector from many possible ones, it is quite easy to get exploited thanks to the skills of many people writing applications on those languages. Removing away the possibility of out of bounds errors and pointer misuse, not possible in other safer systems programming languages, already removes away many of those attacks. So nowadays we have to deal with compiling with -Wall -Wpedatic -Werror, coupled with valgrind like tools and static analyzers to achieve some level of confidence that undefined behaviors and pointer misuses are not creeping in the code. You are right, this is only a small step in the whole security picture, there is also SQL injection, social engineering and many other forms of attacks. Still buffer overflow exploits remain one of the first forms of attack. I do code in C++ since the ARM days, so I do know it quite well. Not making this argument as an anti-C++ zealot.
    - jokoon 13y ago
      > Yes. > Although the insecure design of C and C++ (thanks to its C underpinnings) are just an attack vector from many possible ones, it is quite easy to get exploited thanks to the skills of many people writing applications on those languages. You can't have both performance AND remove the chances programmers will make mistakes. A tool is a tool with its compromises, you can't have all the advantages. > Removing away the possibility of out of bounds errors and pointer misuse, not possible in other safer systems programming languages, already removes away many of those attacks. Then don't use pointers, or learn how to use them properly. You should not hack into pointers anyway, there are never good reason to do so, both for risks of bugs and reduced code re-usability. STL containers make pointer use already quite almost irrelevant. And if it's only C, not C++, I'd argue that C is quite an old system language. Security is an expensive feature, and you're free to code faster without minding security if the business you're doing allows it. The better solution in all this, is using solutions like Cython, or make tools that allows easier bindings with C++ libraries. It doesn't change the fact that often, you'll need to optimize a part of your code, and you'll need to make a C/C++ library out of it, which you'll link against. All this process is quite not standard, and will cost time and learning, because it's quite painful. Security is often not worth the effort. Often it's much more easier to make sure users are using secure applications and securing your network and teaching users about security, than hire a security expert to review your code. And by the way, if someone hack into your system and steal stuff, it's still a criminal act, it's not the fault of the guy who decided to use C++ because he needed speed.
      - pjmlp 13y ago
        > You can't have both performance AND remove the chances programmers will make mistakes. A tool is a tool with its compromises, you can't have all the advantages. Ada is a possible compromise. Modula-2 used to be one as well, before C got spread outside of UNIX. > And if it's only C, not C++, I'd argue that C is quite an old system language. Security is an expensive feature, and you're free to code faster without minding security if the business you're doing allows it. Yes, it is about C. C++ security flaws are a consequence of its C compatibility. Nowadays security is a must for everything except toy programs.

coldtea 13y ago

Well, Rust is your best bet for now, seeing that Go screwed it.

pjmlp 13y ago
Or D, Ada, SPARK