As someone who only has a passing knowledge of C, why is that wrong? Is it because it should be "uint_64" instead?
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.
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.
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.
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.
> For two, it's poorly optimized, when compared to C
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.
By the way, MS's compiler has had stdint.h since 2010. So they are making improvements, slowly.
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.
Floating point math in low level C code is very often a WTF. You most often want integers.
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.
https://en.wikipedia.org/wiki/Extended_precision#x86_extende...
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].
This will mess up all kinds of sharp comparisons on the result of casted operations.
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.
[0] https://www.osr.com/blog/2015/05/27/newbie-corner-theres-typ...