Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C Is Not Reasonable

osr.com

Post reply on HN
Print view View original

1–10 of 71 posts

Re: C Is Not Reasonable

#2

Post by wott »

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.

Re: C Is Not Reasonable

#3

Post by merraksh » 

  ULONGLONG tableOffset;

  tableOffset = (l1Index * L1_TABLE_GRANULARITY) +
                (l2Index * L2_TABLE_GRANULARITY) +
                startingL3->StartingOffset;
I'm tempted to point out that there's some HTML mishap, but actually the statement will be compiled if there is a variable called gt and one called StartingOffset.

Re: C Is Not Reasonable

#4

Post by OskarS »

wott wrote: 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?

Re: C Is Not Reasonable

#6

Post by xgbi »

OskarS wrote: post #4
wott wrote: 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?

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.

Re: C Is Not Reasonable

#7

Post by pjc50 »

Arithmetic is surprisingly hard to get "right". You might try to generalise from this example that "multiplying two N bit numbers together should give a result 2N" wide, then discover that for simple examples you run out of machine bits. Then there's overflow/saturation handling, which is a mess everywhere: lots of systems have hardware support for saturation arithmetic, but you can't conveniently specify it in C.

If anyone could think of a good, concise way of expressing all these bells and whistles of arithmetic, it could be implemented as a language or language frontend. For now, most languages choose to either ignore it entirely or push the user to floating or arbitary-precision arithmetic as an 'improvement'.

Re: C Is Not Reasonable

#8

Post by runeb »

OskarS wrote: post #4
wott wrote: 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?

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.

Re: C Is Not Reasonable

#9

Post by Kenji »

It's really simple, I have a table hanging right by my screen that has type of Operand1 and type of Operand2 and then the type of the result. It has never been an issue. In general, the result is always cast towards the larger and unsigned type.

Re: C Is Not Reasonable

#10

Post by haberman »

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 independently of what it is being assigned to. I have a feeling that the author's preferred behavior would lead to some surprising results, but I can't think of any good examples off the top of my head.

Post reply on HN