3 ms·

Well don't use it. You aren't the target customer because for me, fixing the performance bottleneck is a lot harder than finding a divide by zero, and I certain

Well don't use it. You aren't the target customer because for me, fixing the performance bottleneck is a lot harder than finding a divide by zero, and I certainly don't want to pay for the compiler to check things like divide-by-zero without me asking it to. When I don't care about performance, I reach for a scripting language or something. It's a tool, don't get all emotionally worked up about it.

dagenix 8y ago
> don't get all emotionally worked up about it. Not constructive
pjmlp 8y ago
We are entitled to be emotional about it, because we all have to use tools which have the misfortune to be written in C derived languages. Even if I don't touch those languages for production code, my whole stack safety is dependent how well those underlying layers behave, and how responsibile the developers were towards writing secure core. Which as proven by buffer oveflows in IoT devices not much.
- xmiller 8y ago
  So where is your production code written in Ada or Pascal?
  - pjmlp 8y ago
    Ada cannot tell. Pascal was replaced by Java and C#.
    - jacoblambda 8y ago
      Ada absolutely can tell. Divide by zero throws an exception and buffer overflows are caught by essentially every modern compiler.
      - jstimpfle 8y ago
        > buffer overflows are caught by essentially every modern compiler. If you use high-level arrays with bounds-checking, which are not always fast enough, and can become a maintenaince burden. If they should be absolutely secure (like, std::vector isn't - it can be moved behind your back), they also require GC.
      - pjmlp 8y ago
        Sure it can, but that wasn't the question. Rather what happened to the code I have written. NDAs make us not able to tell about stuff. What magic variant of C or C++ compiler are you using that throws errors on buffer corruption, unless you are speaking about using code with debugging mode enabled in production instead of using a proper release build.

dagenix 8y ago

> don't get all emotionally worked up about it. Not constructive

pjmlp 8y ago

We are entitled to be emotional about it, because we all have to use tools which have the misfortune to be written in C derived languages. Even if I don't touch those languages for production code, my whole stack safety is dependent how well those underlying layers behave, and how responsibile the developers were towards writing secure core. Which as proven by buffer oveflows in IoT devices not much.

xmiller 8y ago
So where is your production code written in Ada or Pascal?
- pjmlp 8y ago
  Ada cannot tell. Pascal was replaced by Java and C#.
  - jacoblambda 8y ago
    Ada absolutely can tell. Divide by zero throws an exception and buffer overflows are caught by essentially every modern compiler.
    - jstimpfle 8y ago
      > buffer overflows are caught by essentially every modern compiler. If you use high-level arrays with bounds-checking, which are not always fast enough, and can become a maintenaince burden. If they should be absolutely secure (like, std::vector isn't - it can be moved behind your back), they also require GC.
    - pjmlp 8y ago
      Sure it can, but that wasn't the question. Rather what happened to the code I have written. NDAs make us not able to tell about stuff. What magic variant of C or C++ compiler are you using that throws errors on buffer corruption, unless you are speaking about using code with debugging mode enabled in production instead of using a proper release build.