6 ms·

This comes with me not being very experienced or familiar with C, but this is... disturbing. I mean, I totally get that this is a really poor use case, and as

This comes with me not being very experienced or familiar with C, but this is... disturbing. I mean, I totally get that this is a really poor use case, and as I just learned from looking it up (because I didn't know this before), sizeof in C isn't a function or macro, but an operator. That just doesn't jibe with the mental model of C that I had in my head. And programming languages, if anything, should be conducive to mental models, not hostile to them.

jjnoakes 10y ago
> That just doesn't jibe with the mental model of C that I had in my head I'm curious, what mental model of sizeof() did you have in your head, and how did it work?
ori_b 10y ago
But it can't be a function, because functions don't have access to that information.
notalaser 10y ago
One could equally point out that programmers should form mental models by reading documentation, rather than relying on intuition. It's not like you have to dig through compiler sources to find out that sizeof is an operator. Even if it wasn't plainly documented in pretty much any properly-written material on the C programming language, it's pretty obvious that sizeof can't be a function, since a function doesn't have access to the sort of data required in order to retrieve this sort of information.
- dbaupp 10y ago
  The reality is people form mental models by intuition. Things designed for humans to use (like programming languages) should take this reality into account.
  - bandushrew 10y ago
    The reality is that any model formed for any programming language that isn't based on reading the documentation has no chance of being correct...
    - dbaupp 10y ago
      Whether or not that is true, that doesn't contradict what I said. Taking into account intuition doesn't mean one can't or shouldn't do some unintuitive things, just that it should be an explicit decision. In the extreme, no amount of documentation about how the "+" operator does a multiplication is going to make that a good language design choice, and this applies to smaller papercuts too.
  - notalaser 10y ago
    And then people wonder why other engineers smirk when they hear the term "software engineering" :-). We're not all fitted with the same Umbrella IntuCard Mk. II Intuition card so that, relying on intuition alone, we can all reach the same results from the same inputs. Relying on intuition to figure out how a language works is about as smart as relying on intuition to figure out the limit of a series, how a telephone work or how a transistor works -- all three of which have been definitely designed for humans to use, since there were nothing but humans who could use them back when they were invented. I don't like it any more than you do, and my life would be much easier (and probably happier) if it weren't like this, but blaming it on the language is the equivalent of the turtle blaming calculus after losing the race to Achiles.
    - dbaupp 10y ago
      I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions. The packaging is, but I'd argue that the packaging for both is relatively intuitive for someone likely to be encountering them. For this example, there is a large amount of intuition both from C specifically and more broadly in programming (i.e. the background of people likely to be encountering this) that foo(bar) is a function call that evaluates all its various components. The syntax used for many "calls" of sizeof violate this intuition. The uniformity that leads to this corner case may indeed be the right choice (and probably actually is, IMO), but discarding intuition---and assuming everyone is a robot who's memorised all corner cases of their tools and never makes a mistake---is dumb, especially in a relatively restricted domain like programming where there is a reasonable set of common/shared assumptions to build on. Lastly, the "a good carpenter never blames their tools" sentiment is also dumb, as a universal guideline: tooling can be objectively bad and unhelpful, and, even if someone can make it work, there will be downsides. Taking things to the limit, it's clear that "C but instead of text, just write down the UTF-8 encoding of a file as one huge base-10 number" would be an actively bad programming language and lead to all sorts of problems over normal C. The same thing holds for, say, C compared to other tools: people make objectively more of certain particularly bad classes of errors when writing C because the tool isn't helpful enough.
      - 10y ago
matthewaveryusa 10y ago
It was a bug introduced in C99 -- C versions before this did not have this bug. I would say it's an extreme oversight on the part of the standardization committee. They standard has this whimsical statement: >Where a size expression is part of the operand of a sizeof operator and changing the value of the size expression would not affect the result of the operator, it is unspecified whether or not the size expression is evaluated. I think it's a long-winded way of saying "my bad"
mikeash 10y ago
I'm going to be that guy for a moment and ask: why were you using sizeof without ever looking it up to find out what it was? I don't expect programmers to be perfect, but some basic RTFM before using a new construct doesn't seem too much to ask.

jjnoakes 10y ago

> That just doesn't jibe with the mental model of C that I had in my head I'm curious, what mental model of sizeof() did you have in your head, and how did it work?

ori_b 10y ago

But it can't be a function, because functions don't have access to that information.

notalaser 10y ago

One could equally point out that programmers should form mental models by reading documentation, rather than relying on intuition. It's not like you have to dig through compiler sources to find out that sizeof is an operator. Even if it wasn't plainly documented in pretty much any properly-written material on the C programming language, it's pretty obvious that sizeof can't be a function, since a function doesn't have access to the sort of data required in order to retrieve this sort of information.

dbaupp 10y ago
The reality is people form mental models by intuition. Things designed for humans to use (like programming languages) should take this reality into account.
- bandushrew 10y ago
  The reality is that any model formed for any programming language that isn't based on reading the documentation has no chance of being correct...
  - dbaupp 10y ago
    Whether or not that is true, that doesn't contradict what I said. Taking into account intuition doesn't mean one can't or shouldn't do some unintuitive things, just that it should be an explicit decision. In the extreme, no amount of documentation about how the "+" operator does a multiplication is going to make that a good language design choice, and this applies to smaller papercuts too.
- notalaser 10y ago
  And then people wonder why other engineers smirk when they hear the term "software engineering" :-). We're not all fitted with the same Umbrella IntuCard Mk. II Intuition card so that, relying on intuition alone, we can all reach the same results from the same inputs. Relying on intuition to figure out how a language works is about as smart as relying on intuition to figure out the limit of a series, how a telephone work or how a transistor works -- all three of which have been definitely designed for humans to use, since there were nothing but humans who could use them back when they were invented. I don't like it any more than you do, and my life would be much easier (and probably happier) if it weren't like this, but blaming it on the language is the equivalent of the turtle blaming calculus after losing the race to Achiles.
  - dbaupp 10y ago
    I don't see how your series or resistor examples are particularly relevant: neither mathematical nor physical facts are human inventions. The packaging is, but I'd argue that the packaging for both is relatively intuitive for someone likely to be encountering them. For this example, there is a large amount of intuition both from C specifically and more broadly in programming (i.e. the background of people likely to be encountering this) that foo(bar) is a function call that evaluates all its various components. The syntax used for many "calls" of sizeof violate this intuition. The uniformity that leads to this corner case may indeed be the right choice (and probably actually is, IMO), but discarding intuition---and assuming everyone is a robot who's memorised all corner cases of their tools and never makes a mistake---is dumb, especially in a relatively restricted domain like programming where there is a reasonable set of common/shared assumptions to build on. Lastly, the "a good carpenter never blames their tools" sentiment is also dumb, as a universal guideline: tooling can be objectively bad and unhelpful, and, even if someone can make it work, there will be downsides. Taking things to the limit, it's clear that "C but instead of text, just write down the UTF-8 encoding of a file as one huge base-10 number" would be an actively bad programming language and lead to all sorts of problems over normal C. The same thing holds for, say, C compared to other tools: people make objectively more of certain particularly bad classes of errors when writing C because the tool isn't helpful enough.
    - 10y ago

matthewaveryusa 10y ago

It was a bug introduced in C99 -- C versions before this did not have this bug. I would say it's an extreme oversight on the part of the standardization committee. They standard has this whimsical statement: >Where a size expression is part of the operand of a sizeof operator and changing the value of the size expression would not affect the result of the operator, it is unspecified whether or not the size expression is evaluated. I think it's a long-winded way of saying "my bad"

mikeash 10y ago

I'm going to be that guy for a moment and ask: why were you using sizeof without ever looking it up to find out what it was? I don't expect programmers to be perfect, but some basic RTFM before using a new construct doesn't seem too much to ask.