C Is Not Reasonable

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

>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

For modern applications programming, arbitrary-precision is probably the right way to do integer arithmetic. Python does that, and it doesn't seem to cause any trouble. The people who need to do massive amounts of numeric stuff know who they are and can take the time to learn the relevant arcana, but your typical cat pictures app never has to worry about how big any of its integers are.

Yeah, I recently read on some forum someone who was looking for a quick C++ training for a friend and said "he doesn't need a deep training, just some basic syntax, he's not a programmer, that doesn't interest him, he's just doing scientific calculus".

I was like: Oh boy... getting arithmetic calculation right is really tricky and you have to understand many not-obvious details, especially concerning the behaviour of floating-points numbers, and then you have to make choices or compromises depending on your requirements. But if you have no idea of the limitations of CPUs and languages, the naïve requirement is just "exact, full-precision, as long as needed" and you'll hit some bugs sooner or later.

> then discover that for simple examples you run out of machine bits

Why? I don't think it would be common to run out of machine bits for correct programs (and not really run out, just go into bigints in some cases). But the compiler cannot calculate those bits based on machine types, instead it should track all possible values/ranges and multiply them too to decide whether the result could fit into the type or it needs a bit bigger one. And since values don't appear out of thin air, but come from literals or some input and checked for specific ranges all the time, it should be possible to automatically choose appropriate types and only warn about possible overflows or performance penalties due to bigints.

Naive approach of multiplying machine types is pointless, of course, on that I agree.

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.

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

Agreed, though recent crop of languages with less implicit conversion will reject the entire thing rather than silently expand the value at the end, e.g. in Rust

    error[E0308]: mismatched types
     --> <anon>:7:19
      |
    7 |     tableOffset = (l1Index * L1_TABLE_GRANULARITY) +
      |                   ^ expected u64, found u32
    
    error: aborting due to previous error

Looks like a use-case for typeclasses, e.g. those in Haskell. A typeclass is like a Java interface, except the method lookup can use the return type as well.

For example, we could make "plus" depend on the return type:

    -- "plus" takes two instances of "Number" and returns an "a"
    class Additive a where
      plus :: (Number b) => b -> b -> a

    -- Take two Numbers and return an Int
    instance Additive Int where
      plus x y = intPlus (toInt x) (toInt y)

    -- Take two Numbers and return a Float
    instance Additive Float where
      plus x y = floatPlus (toFloat x) (toFloat y)

We can even abuse this to do ugly hacks, like making "plus x y" return a list of "[x + y]" when the return type requires a list:

    -- Take two Numbers and return a list containing their sum
    instance (Additive a) => Additive (List a) where
      plus x y = [plus x y]

Alternatively, we could have returned "[plus x 0, plus y 0]" to make things even uglier ;)

The surprise would be if you wanted to, say, add 100 to a uint8 and have it wrap, but were assigning the result to a uint64. Then your arithmetic wouldn't wrap, unless you explicitly told it to, i.e. "x = (y + 100) & 0xff;"

Either way leads to surprises if your intuition tells you the other thing should happen.

Strictly, in C the behaviour is undefined when a signed integer overflows. Although it wouldn't help in the author's case, since he's using unsigned integers, it is valid for a compiler to internally promote the operands of signed arithmetic.

Indeed. The post begins with a question and asserts that the reader doesn't know the answer. I knew the correct answer instinctively and I haven't written any C in anger in years. Expecting a C compiler to promote expression operands prior to assignment because the output location is a larger size... that's just not the mentality C programmers develop; what if the output is smaller? Should all the expression operands be demoted automatically, producing radically different results as large numbers get truncated prior to evaluation? No. Obviously not. That sort of thing is self-evident to a competent C programmer.

C portability is not portability in the Java or Python sense. It's portability across architectures, and undefined (and implementation-defined) behavior is a powerful tool for that.

If it were consistent with FLT_EVAL_METHOD==2, then it would evaluate in the highest precision available.

There's a lot of smug criticism of this article, but there actually is a reasonable point that FLT_EVAL_METHOD is inconsistent with the way integers are handled in C.

Whilst the delivery could be better, I agree with the sentiment that operator precedence is a waste of time. It's exactly the kind of mundane, error-prone work that machines should be doing for us, whether it's via a sophisticated structured editor, or a simple hack like Emacs's various paredit-like modes.

> Sure, you can pepper all your code in parentheses, but sooner or later you're going to come across code that doesn't. And a person like that working on such a codebase is a huge danger.

I can certainly imagine someone who doesn't care about precedence using an editor which disambiguates such things automatically; either by adding parentheses, colouring the background, etc. I can also imagine such a person spotting precedence bugs introduced by a colleague who considered themselves to be above such tooling.

Lisp, Forth and friends do perfectly well without having to consult precedence tables, and whilst I appreciate that some would prefer more syntax than those provide, I think precedence rules should still stick to the meta-level, parser-directing stuff like block delimiters, statement separators ("x ; y"), and maybe syntax sugar like "," ".", "=", etc. If it can be written as a library (which certainly includes things like numeric procedures) then it shouldn't have any precedence.

Even this minimal amount of precedence should be avoidable if desired, e.g. to avoid ambiguities like "a = b xor c". In PHP this parses to "(a = b) xor c", which is a perfectly valid PHP expression and caused the most egregious waste of my time to date.

Whilst it's true that learning and applying "BODMAS" is simple enough to do in high school arithmetic, the context of high school arithmetic is vastly impoverished compared to computer programming.

For example, which has the higher precedence: integer multiplication or list append? What about floating-point division compared to image convolution? Tree construction or matrix subtraction?

I think such questions are silly, yet they're a legitimate concern in languages with heavy use of infix notation (e.g. Haskell). Languages which define a fixed set of infix operators to avoid such problems (e.g. C) cause an unnecessary asymmetry between operators and every other procedure (e.g. think about the number of times "function(x, y) { return x + y; }" has been written by Javascript programmers!), and are impoverishing their domain of discourse much like high school arithmetic (e.g. compare introductory C material to something like https://code.world/doc.html?help/codeworld.md or http://www.bootstrapworld.org/materials/spring2016/tutorial )