5 ms·

Because ULONGLONG is reminiscent of Windows, Visual Studio, and its flaky and outdated support for C. It does not remove the argument of C choosing to use the

by xgbi 10y ago

Because ULONGLONG is reminiscent of Windows, Visual Studio, and its flaky and outdated support for C. It does not remove the argument of C choosing to use the type of the operands to determine the width of the calculus, but it shown that this is not portable, standard C. Also, if the guy writes drivers, you should expect him to be aware of these problems, possibly having built an extensive set of preprocessor macros to handle these problems, like all other drivers use. But he seems to just loop into the "modify /compile" until it compiles and behaves, without trying to understand.

omginternets 10y ago
To be fair, though, this entire comment thread echoes the main point of the article: in what world is it reasonable to have to keep track of such things?
- falcolas 10y ago
  Drivers, for one. Any world where performance is so critical that you want to ensure you're fitting as much information as you reasonably can into the L1 and L2 caches for the computations you must do. There's even still a role in this world for people to fine tune the assembly code for a specific execution environment to make their HPC models execute faster.
  - omginternets 10y ago
    Respectfully, this misses my point (which, granted, was poorly explained). The necessary evil here is using low-level languages. The unnecessary evil is using a language like C with arbitrary and highly variant conventions. Better alternatives exist for writing drivers (e.g. Rust). To be clear, historical baggage sometimes dictates that we must use C, but that doesn't change the fact that much of the C world is a footgun, leading to eye-gouging frustration and threads such as this one about the myriad pitfalls associated with the language. The author might not be a good C programmer, but this thread nevertheless supports his point. The necessity of writing C in practice is neither here nor there.
    - falcolas 10y ago
      Rust and its ilk may eventually eat this space, but it doesn't appear ready. For one, it's list of supported architectures is too small. For two, it's poorly optimized, when compared to C. Three, it's still too new - it has only been "stable" for a bit over a year. Four, the static verification tools are not yet there (you still need a way to verify the unsafe portions of code, which will not be trivial in a driver). Do you know of any existing non-toy (i.e. distributed in support of a device) drivers which have been written in Rust? I'd love to see some in action, and will be happy revise my opinion of Rust's capabilities when those drivers start rolling out. Let's be frank for a moment. Rust's biggest advantage in this space is its memory safety. But we've had memory safe languages for as long as we've had C, and they still have not eaten C's lunch. If Rust wants to pave the way into C's territory (and not just C++'s territory), it will need to identify why and address that.
      - steveklabnik 10y ago
        > For two, it's poorly optimized, when compared to C I'd be interested in hearing more about this.
      - omginternets 10y ago
        Okay, point taken, but I'd like to back-pedal a bit if you don't mind. I agree that Rust is very immature, but again I think I misspoke. The basic point I'm trying to make is that C is (a) fraught with historical baggage that makes it difficult to use safely, in practice and that (b) this comment thread proves this point. All points made beyond this are secondary and tangential. Again, I have to agree with you about the maturity of Rust, but I must insist that using C is fraught with absolute insanity. Sometimes it's the only thing available, but it's still insane.
asveikau 10y ago
The ULONGLONG typedef is a 64 bit integer. They should use that. By the way, MS's compiler has had stdint.h since 2010. So they are making improvements, slowly.

by xgbi 10y ago

omginternets 10y ago

To be fair, though, this entire comment thread echoes the main point of the article: in what world is it reasonable to have to keep track of such things?

falcolas 10y ago
Drivers, for one. Any world where performance is so critical that you want to ensure you're fitting as much information as you reasonably can into the L1 and L2 caches for the computations you must do. There's even still a role in this world for people to fine tune the assembly code for a specific execution environment to make their HPC models execute faster.
- omginternets 10y ago
  Respectfully, this misses my point (which, granted, was poorly explained). The necessary evil here is using low-level languages. The unnecessary evil is using a language like C with arbitrary and highly variant conventions. Better alternatives exist for writing drivers (e.g. Rust). To be clear, historical baggage sometimes dictates that we must use C, but that doesn't change the fact that much of the C world is a footgun, leading to eye-gouging frustration and threads such as this one about the myriad pitfalls associated with the language. The author might not be a good C programmer, but this thread nevertheless supports his point. The necessity of writing C in practice is neither here nor there.
  - falcolas 10y ago
    Rust and its ilk may eventually eat this space, but it doesn't appear ready. For one, it's list of supported architectures is too small. For two, it's poorly optimized, when compared to C. Three, it's still too new - it has only been "stable" for a bit over a year. Four, the static verification tools are not yet there (you still need a way to verify the unsafe portions of code, which will not be trivial in a driver). Do you know of any existing non-toy (i.e. distributed in support of a device) drivers which have been written in Rust? I'd love to see some in action, and will be happy revise my opinion of Rust's capabilities when those drivers start rolling out. Let's be frank for a moment. Rust's biggest advantage in this space is its memory safety. But we've had memory safe languages for as long as we've had C, and they still have not eaten C's lunch. If Rust wants to pave the way into C's territory (and not just C++'s territory), it will need to identify why and address that.
    - steveklabnik 10y ago
      > For two, it's poorly optimized, when compared to C I'd be interested in hearing more about this.
    - omginternets 10y ago
      Okay, point taken, but I'd like to back-pedal a bit if you don't mind. I agree that Rust is very immature, but again I think I misspoke. The basic point I'm trying to make is that C is (a) fraught with historical baggage that makes it difficult to use safely, in practice and that (b) this comment thread proves this point. All points made beyond this are secondary and tangential. Again, I have to agree with you about the maturity of Rust, but I must insist that using C is fraught with absolute insanity. Sometimes it's the only thing available, but it's still insane.

asveikau 10y ago

The ULONGLONG typedef is a 64 bit integer. They should use that. By the way, MS's compiler has had stdint.h since 2010. So they are making improvements, slowly.