Live data from Hacker News

C Is Not Reasonable

osr.com

11–20 of 71 posts

Re: C Is Not Reasonable

#11
I really couldn't organize my thoughts from the sheer amount of criticism I have of this blog post. So instead, I'll kindly ask anyone to give this person a "do what I mean, and not what I say" programming language.

And they will realize that even that has quirks.

Re: C Is Not Reasonable

#12
post #4
post #2

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_…

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

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

Re: C Is Not Reasonable

#13
post #4
post #2

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_…

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

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.

Re: C Is Not Reasonable

#14
post #2

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_…

>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

Re: C Is Not Reasonable

#16
The way to understand it is that "+" when applied to ULONGs returns a ULONG. What the heck else it would return, in a language that doesn't have arbitrary precision arithmetic?

Re: C Is Not Reasonable

#17
post #6
post #4

Earlier quoted context omitted.

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

Re: C Is Not Reasonable

#18

It is strange to pick on C for this, as I cannot think of a single language that works the way the author seems to want. The only exception I can think of is Perl, which has the "wantarray" function that lets a function vary its behavior based on what its return is being assigned to: http://perldoc.perl.org/functions/wantarray.html With that exception, it's pretty much always assumed that an expression is evaluated i…

It would be nice if languages allowed us to overload function names with the exact same parameters but different return types. The compiler or runtime environment should be able to select the correct implementation automatically based on type inference, or allow the programmer to specify which one should be used with an annotation. This would make some code a little cleaner instead of having to give all of those functions different names.

Re: C Is Not Reasonable

#20
post #4
post #2

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_…

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

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.

Post reply on HN