Hacker News Reader

Comment by wott | Hacker News Reader

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.

View on HN

>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

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.

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

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.

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?

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.

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.

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.

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.

  >  For two, it's poorly optimized, when compared to C

I'd be interested in hearing more about this.

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.

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.

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.

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.

Sadly, C does not support fixed point arithmetic. You can hack it on top, but the result is super ugly.

> 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.

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_extende...

This will lose precision, as any floating point operation is only accurate to 1 unit in the last place (ULP). Even simple addition.

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].

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.

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.

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-typ...

It's in user mode too - as the return type of GetTickCount64, for example: https://msdn.microsoft.com/en-gb/library/windows/desktop/aa3...

Reply on news.ycombinator.com