4 ms·

First line: > ULONGLONG tableOffset; It's starting well, for a C example... Oh, and it ends even better: > I write drivers for a living, not scientific or s

by wott 10y ago

First line: > ULONGLONG tableOffset; It's starting well, for a C example... Oh, and it ends even better: > I write drivers for a living, not scientific or statistical analysis software. During this project, I quickly learn that casting everything to (double) was my friend. When in doubt, stick a (double) in front of it and test it again. In the end, the code worked pretty well. The customer was happy. We got paid. o_O OKOK, so you write drivers but don't know about C types, standard types, fixed-length types, you randomly fiddle with types until it passes a test but you don't know why it passes or doesn't, and you're proud of selling that. Wonderful. EDIT: added the "even better" part.

OskarS 10y ago
As someone who only has a passing knowledge of C, why is that wrong? Is it because it should be "uint_64" instead?
- 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.
  - 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.
- runeb 10y ago
  Its wrong because you don't understand the problem you're trying to solve nor why the tests passes after randomly trying a double. This is cargo-culting.
- spacehunt 10y ago
  > When in doubt, stick a (double) in front of it If casting from an integer type, this loses precision. Why would this make tests pass? Are there any secondary effects? The author apparently made no effort to find out.
  - dllthomas 10y ago
    This may lose precision. Depending on architecture & compiler & flags, your mantissa may be big enough to hold your whole int. An 80 bit extended double has 64 bits of significand. https://en.wikipedia.org/wiki/Extended_precision#x86_extended_precision_format https://en.wikipedia.org/wiki/Extended_precision#x86_extende...
    - AstralStorm 10y ago
      This will lose precision, as any floating point operation is only accurate to 1 unit in the last place (ULP). Even simple addition.
      - deleted 10y ago
        [deleted]
      - parenthephobia 10y ago
        This conversion will not lose precision! With a 64-bit mantissa, ULP(x) is ≤ 1 for x in [-2e64, 2e64]. If you have the time you can count up to 2^64 by repeatedly incrementing a float80(0.0) by 1. Addition, subtraction and multiplication on float80s are perfectly stable provided the results stays within [-2e64, 2e64].
        AstralStorm 10y ago
        There is no guarantee on stability of those ops. Intel and IEEE guarantees 1 ULP. Even if you use the 80 bit type. The error is not guaranteed to not be additive over multiple operations either. And for multiplication and division? Let's not even go there. This will mess up all kinds of sharp comparisons on the result of casted operations.
- wott 10y ago
  unsigned long long if you want at least a 64-bit unsigned. uint64_t if you want a fixed-length 64-bit unsigned (and your compiler is at least C99, but I think long long came with C99 too). Note that unsigned long is at least 32-bit, so it could be 64-bit too, there is no guarantee it is exactly 32-bit.
- to3m 10y ago
  Well, uint64_t ;) - but ULONGLONG is uint64_t, so it's the same thing. The real "problem" here is presumably that ULONGLONG is a Windows-specific type, probably. (I say probably, because you can always make your own type called ULONGLONG - there's no rule to stop you.) People do like to mock people who program for Windows.
  - stevetrewick 10y ago
    ULONGLONG is in fact a Windows Drivers Kit specific type. WDK has its own specialised set of weird and uncomfortable type conventions in the MS style [0] and although the author's point about C arithmetic type promotion is generic, his context is WDK device drivers, so ULONGLONG is absolutely correct, if possibly somewhat archaic (there's a ULONG64 lately). [0] https://www.osr.com/blog/2015/05/27/newbie-corner-theres-type-unexpected-world-windows-kernel-types/ https://www.osr.com/blog/2015/05/27/newbie-corner-theres-typ...
    - to3m 10y ago
      It's in user mode too - as the return type of GetTickCount64, for example: https://msdn.microsoft.com/en-gb/library/windows/desktop/aa383751%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-gb/library/windows/desktop/aa3...
- asveikau 10y ago
  It's silly because no casts give you an integer type that is too small, but casting to double converts to floating point, performs floating point math, then assigns the result to the correct type they should have used in the beginning. Floating point math in low level C code is very often a WTF. You most often want integers.
  - AstralStorm 10y ago
    Sadly, C does not support fixed point arithmetic. You can hack it on top, but the result is super ugly.
stevetrewick 10y ago
>OKOK, so you write drivers but don't know about C types, standard types, fixed-length types That was my thought as well. I've occasionally been hired to write windows kernel drivers and I'd say that if you don't have a good grasp of stuff like C's type promotion, you're gonna have a bad time. Surprised to see this from OSR, which was a great source of info for driver development arcana when I was doing it. Edit: remove repeated phrase
- oconnore 10y ago
  You're both missing the point. Knowing the rules is not the same thing as consistently applying the rules across code you wrote or didn't write (or wrote late at night). The first is easy for a human, the second is hard for a human. That's why language researchers post-1972 have had jobs.

by wott 10y ago

OskarS 10y ago

As someone who only has a passing knowledge of C, why is that wrong? Is it because it should be "uint_64" instead?

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.
- 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.
runeb 10y ago
Its wrong because you don't understand the problem you're trying to solve nor why the tests passes after randomly trying a double. This is cargo-culting.
spacehunt 10y ago
> When in doubt, stick a (double) in front of it If casting from an integer type, this loses precision. Why would this make tests pass? Are there any secondary effects? The author apparently made no effort to find out.
- dllthomas 10y ago
  This may lose precision. Depending on architecture & compiler & flags, your mantissa may be big enough to hold your whole int. An 80 bit extended double has 64 bits of significand. https://en.wikipedia.org/wiki/Extended_precision#x86_extended_precision_format https://en.wikipedia.org/wiki/Extended_precision#x86_extende...
  - AstralStorm 10y ago
    This will lose precision, as any floating point operation is only accurate to 1 unit in the last place (ULP). Even simple addition.
    - deleted 10y ago
      [deleted]
    - parenthephobia 10y ago
      This conversion will not lose precision! With a 64-bit mantissa, ULP(x) is ≤ 1 for x in [-2e64, 2e64]. If you have the time you can count up to 2^64 by repeatedly incrementing a float80(0.0) by 1. Addition, subtraction and multiplication on float80s are perfectly stable provided the results stays within [-2e64, 2e64].
      - AstralStorm 10y ago
        There is no guarantee on stability of those ops. Intel and IEEE guarantees 1 ULP. Even if you use the 80 bit type. The error is not guaranteed to not be additive over multiple operations either. And for multiplication and division? Let's not even go there. This will mess up all kinds of sharp comparisons on the result of casted operations.
wott 10y ago
unsigned long long if you want at least a 64-bit unsigned. uint64_t if you want a fixed-length 64-bit unsigned (and your compiler is at least C99, but I think long long came with C99 too). Note that unsigned long is at least 32-bit, so it could be 64-bit too, there is no guarantee it is exactly 32-bit.
to3m 10y ago
Well, uint64_t ;) - but ULONGLONG is uint64_t, so it's the same thing. The real "problem" here is presumably that ULONGLONG is a Windows-specific type, probably. (I say probably, because you can always make your own type called ULONGLONG - there's no rule to stop you.) People do like to mock people who program for Windows.
- stevetrewick 10y ago
  ULONGLONG is in fact a Windows Drivers Kit specific type. WDK has its own specialised set of weird and uncomfortable type conventions in the MS style [0] and although the author's point about C arithmetic type promotion is generic, his context is WDK device drivers, so ULONGLONG is absolutely correct, if possibly somewhat archaic (there's a ULONG64 lately). [0] https://www.osr.com/blog/2015/05/27/newbie-corner-theres-type-unexpected-world-windows-kernel-types/ https://www.osr.com/blog/2015/05/27/newbie-corner-theres-typ...
  - to3m 10y ago
    It's in user mode too - as the return type of GetTickCount64, for example: https://msdn.microsoft.com/en-gb/library/windows/desktop/aa383751%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396 https://msdn.microsoft.com/en-gb/library/windows/desktop/aa3...
asveikau 10y ago
It's silly because no casts give you an integer type that is too small, but casting to double converts to floating point, performs floating point math, then assigns the result to the correct type they should have used in the beginning. Floating point math in low level C code is very often a WTF. You most often want integers.
- AstralStorm 10y ago
  Sadly, C does not support fixed point arithmetic. You can hack it on top, but the result is super ugly.

stevetrewick 10y ago

>OKOK, so you write drivers but don't know about C types, standard types, fixed-length types That was my thought as well. I've occasionally been hired to write windows kernel drivers and I'd say that if you don't have a good grasp of stuff like C's type promotion, you're gonna have a bad time. Surprised to see this from OSR, which was a great source of info for driver development arcana when I was doing it. Edit: remove repeated phrase

oconnore 10y ago
You're both missing the point. Knowing the rules is not the same thing as consistently applying the rules across code you wrote or didn't write (or wrote late at night). The first is easy for a human, the second is hard for a human. That's why language researchers post-1972 have had jobs.