Humans should think of sizeof() as a function, says Linus Torvalds

https://lkml.org/lkml/2012/7/11/103

by arjun024 • 11 years ago

111 132 11 years ago

lkml.org

mburns• 11 years ago

(2012)

lazzlazzlazz2• 11 years ago

Who the hell doesn't think of `sizeof` as a function?

Luc• 11 years ago

I learned C from 'Kernighan & Ritchie', where it's never referred to as a function but as a compile-time operator. I've never thought of it as a function.

_lce0• 11 years ago

Well it's an operator, and algebra said all them are just functions... Just like `+` is a function

Anyways not all those writing code have CS background

masklinn3• 11 years ago

Except sizeof is a compile-time operation, not runtime. If sizeof were a function,

    int *foo = malloc(sizeof(*foo));

would make no sense.

weland• 11 years ago

Except algebra said that about algebraic functions and operators.

I know a CS major who insisted in pointing out the same thing. He was extremely surprised when dragons hatched from his eggs instead of the chickens he expected. It was a really heated event. He barely escaped -- and then ranted for several weeks how they were really just eggs and couldn't explain what happened.

noselasd• 11 years ago

It's an unary operator, with 2 forms:

   sizeof(type)

  sizeof expression

but e.g. unlike a function, it doesn't evaluate the expression.

    sizeof(my_function()) doesn't call my_function.

    sizeof(a = 12) doesn't assign 12 to a.

Retr0spectrum• 11 years ago

So is "sizeof(a = 12)" equivalent to just "sizeof(a)"?

lazzlazzlazz2• 11 years ago

That's a language design choice - not a conceptual argument.

krylon6• 11 years ago

IIRC, if the argument to sizeof is a type, the parentheses are mandatory, anyway, so using it like it was a function is more consistent.

I think the reason it is not a function from the standard's point of view is that C does not have any builtin functions (unless my memory totally fails me in this case), all functions have to be either defined locally or #included.

netheril962• 11 years ago

Exactly.

I heard people arguing on the Internet that you should not add parentheses when sizeof is applied to an expression, only a type. I just cannot understand why they bother. Just add a parenthesis and it is always right. Much less cognitive burden.

raverbashing3• 11 years ago

This is the same people that find it "better" to write JS without the semicolons.

eliben• 11 years ago

it is not a function from the standard's point of view is that C does not have any builtin functions

The problem with sizeof is that is should be able to accept a type as an argument. No function in C can do that, according to the standard C grammar.

Somewhat similarly, the standard va_arg is a macro, not a function, also because it accepts a type.

barrkel3• 11 years ago

Another oddity of C that amuses me is the do/while loop without braces:

    int i = 4;
    do
       printf("hey\n");
    while (--i > 0);

Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles). So everybody uses braces, and thus it looks quite disturbing without them.

cygx3• 11 years ago

it looks quite disturbing without them

Remove the newline and it looks ok to me:

    int i = 42;
    do printf("hey\n");
    while (--i > 0);

Another possibility would be:

    int i = 42;
    do printf("hey\n");
        while (--i > 0);

kevin_thibedeau• 11 years ago

Its not so disturbing when you consider that braces aren't special cased in the C grammar. They group statements so they can be used together where a statement is needed. From the grammar's perspective the "normal" way is without braces. It's just that all the C-alikes have gone a different direction with the way braces are parsed leading everyone to regard the original behavior in C as ugly warts.

gumby3• 11 years ago

Another oddity of C that amuses me is the do/while loop without braces: [...] Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles).

Ah, but don't forget you can still use the comma operator, so get several statements in before the semicolon:

    int i = 4;
    do
       printf("hey"), printf("Jude.\n");
    while (--i > 0);

weinzierl• 11 years ago

In C there are no functions that take a type as argument.

   sizeof(type)

is a special case anyway.

I'm all for using sizeof like a function, but that doesn't make it consistent. sizeof is just a special syntactical construct.

I like to think that sizeof is called an operator just for syntactic convenience much in the same way as typedef is a storage-class specifier.

masklinn3• 11 years ago

And you really shouldn't use it with a type if you can avoid it anyway, it makes code brittle e.g.

    int *foo;
    // code
    foo = malloc(sizeof(int));

a few months later, change foo to be a double. Code still compiles, no warning, but you're allocating half the memory you need.

ksherlock• 11 years ago

There are standard macros (va_arg, I'm looking at you) that take a type as an argument.

Udo2• 11 years ago

I'd like to confess that I'm one of the return() people, and I also do if() even in cases where the language doesn't require it. This behavior isn't borne out of confusion about what is and what isn't a special language construct. Rather, it helps me prop up the illusion that programming is about using a few simple primitives instead of being the chain of compiler directives it actually entails - it's an esthetic choice if not always a logical one.

The thought that if() could just be a lazily-evaluated function taking a code block argument, and that return() could be a way of marking the end result of an expression somehow pleases me.

I think the different expectations about sizeof() come from the artificial distinction between operators and functions, the implication being that in a compiled language the sizeof operator would be a compile-time construct, or barring that, at least a behavior of the type system. On the other hand, there are tons of compiler intrinsics in C/C++ that look exactly like functions but aren't.

sedeki• 11 years ago

Doesn't `if` always require parenthesizes?

elisee• 11 years ago

Yes, in C, but I believe Udo was talking about other languages (like Go for instance)

and I also do if() even in cases where the language doesn't require it

This sentence could be parsed in multiple ways though :)

zoul• 11 years ago

Not in all languages. For example, Go and Swift don’t require it.

Udo2• 11 years ago

No, not always. Not in Go, or in Rust, or Ruby, for example. The assumption being in these languages that if is followed by an expression and that expression is parsed to its natural end anyway - but this only works if the syntax allows for that end to be found without ambiguity.

nikai• 11 years ago

Not even in C. You can have an if condition that is actually a macro that expands with parentheses. For example the macros in ctype.h, so you can actually write

  if islower(c) {
      (..)
  }

soup10• 11 years ago

What kind of monsters don't use parentheses on sizeof. Is it the same guys that put { on new lines and have giant comment templates for every one line function.

michaelmior• 11 years ago

{ on new lines seems to have dominated the majority of code I've worked with although I've always preferred putting it on the same line myself.

pivo2• 11 years ago

I put it on the line that makes the code following it the most clear

harkyns_castle• 11 years ago

Most C++ codebases I've seen have the brace on a fresh line, most Java codebases at the end of the line (at a guess born of the Sun guidelines and default Eclipse formatting perhaps). I started with the former, but prefer the latter now.

To me its more about conserving an extra bit of vertical space... I like my methods/functions quite compact. In the past I liked the balanced nature of the braces though.

Makes absolutely no appreciable difference though of course, as long as you don't get into a formatting war with your team.

MrBuddyCasino4• 11 years ago

Ah, to join the bikeshedding: { on newlines make imho more sense, the block of code is visually balanced that way. We have high-res screens now, no reason to pretend we're still on 80 char terminals.

But work long enough in either one of those styles, and the other one will start to look strange.

heisenbit• 11 years ago

We got higher resolution and with it not taller but wider screens. So following your reasoning the { should be on the right ;-)

Retra• 11 years ago

What advantage does 'visually balanced' give? That's like saying the letter A is better than B because it's 'stands up better.'

Indentation is how you should identify blocks.

progrn• 11 years ago

But, I cannot get a function pointer to it, right?

krylon6• 11 years ago

Exactly.

fnthrowa98• 11 years ago

It is a function in the mathematics sense, not the C sense.

wz10003• 11 years ago

"return()" is in no way a function.

Ah, but in Haskell, `return` is a function, though it shares only a few similarities with with its counterpart in C-like languages.

However, when using continuations or a continuation passing style, the continuation is a function that behaves almost exactly like traditional return when called!

    (define (multiply x y return)
      (return (* x y)))

wz10003• 11 years ago

Was there something factually incorrect in my comment?

stonogo• 11 years ago

Was there something relevant in your comment?

mattkrea• 11 years ago

Just as annoying as people not using parens with "typeof()" in JavaScript.

Negative12• 11 years ago

I respect Linus greatly but the way he to talks to his fellow 'humans' is insanely confrontational, rude and disrespectful. It overshadows his arguments (which are usually very good) and throws people on the defensive. I'm grateful for all he has accomplished and shared with us but I imagine working with him is 'hell'.

moonbug2• 11 years ago

Agreed. Not sure which is worse - that he's a terrible role model, or that he's proud of that fact.

topkekz• 11 years ago

http://www.catb.org/esr/faqs/smart-questions.html#keepcool

mcguire4• 11 years ago

Keep in mind: that's the dipshit that thinks he's the avatar of Pan.

tormeh2• 11 years ago

Making others feel warm and fuzzy is one of the most important things in life. I don't like that it's downplayed.

douche2• 11 years ago

I would imagine once you get used to him and thicken your skin up a bit, it's no big deal.

Hell, a little salty language and telling people they're being idiots when they are being idiots is not a bad thing. The best machinists and millwrights I've worked with were like that, and it was a good thing - you don't have time to ask politely when there are steal beams or a two-ton electric motor swinging towards you.

C can be almost as dangerous :-)

twerquie• 11 years ago

He literally says that those who disagree with his code style should be shot. That's completely unacceptable language to use and makes him sound like he hasn't mastered English. I'm not sure anyone should take c-language style tips from such a boor.

return0• 11 years ago

I quite enjoy his style, but i understand it's not for the newer "easily triggered" generations

nmj• 11 years ago

Here's an example of a really bad use of "sizeof" that doesn't have the parenthesis around the argument: sizeof(*p)->member. Quite frankly, if you do this, you should be shot.

Good ol' Linus

thomasahle• 11 years ago

I certainly read that the wrong way first time around.

moonbug2• 11 years ago

"Quite frankly, if you do this, you should be shot. "

Ah, yes. No comment from Torvalds is complete without a gratuitous ad hominem.

falcolas• 11 years ago

To be fair, he's referring to the code `sizeof(*p)->reference`, in which case I'd probably shoot the writer too.

sfk• 11 years ago

I'm sure he'd appreciate a memo from Sam Altman about gratuitous negativity.

loup-vaillant• 11 years ago

This is not an ad hominem argument. This is merely blowing things out of proportion. This would be ad hominem (and non-sequitur):

"You're watching dancing bunnies, and you dare suggest we should remove the parens after sizeof?"

Attack on the person (watching dancing bunnies), used to discredit an unrelated opinion (parens after sizeof).

gpvos2• 11 years ago

I used to write

    return (0);

I.e., with a space. I'm not sure if someone ever told or recommended me to do this, but the reason I did this was consistency with other C statements, because all C statements that take some kind of expression as a parameter (if, for, while) require it to be surrounded by parentheses. So it seemed logical to me to do the same with return. I've stopped doing it now, although some of the old code still lives.

I've seen code by others where there was always a space between the function name and its arguments. That was ugly, and really confused a function call with a statement.

krylon6• 11 years ago

I find parens around a return value/expression slightly annoying, but not annoying enough to have a debate over it. It doesn't make the code harder to read, IMHO.

Whitespace between a function name and the arguments is significant, however, because with a function-like macro, there must be no whitespace between the name and the opening parenthesis. I've seen the following code in production code, for example:

  #include <stdlib.h>
  #define free(x) free(x), x = NULL

  free(ptr1); // Macro
  free (ptr2); // Call free(3) directly

(Whether or not such a macro is good idea is a different question entirely, the point is that you can prevent such macro-expansion by using whitespace. Aesthetically, I find it very disturbing, though.)

rwallace2• 11 years ago

You do need to omit whitespace between the name and the opening parenthesis when defining a functionlike macro, but it doesn't matter when you're calling it.

tormeh2• 11 years ago

Why is this important?

kazinator2• 11 years ago

Yes, return can be a function. Torvalds hasn't heard of continuations, obviously, where we "return" from a function by invoking a continuation.

We can justify writing return (expr); using the same arguments that justify the sizeof (expr) convention.

The thing is that in C, return isn't a function; there are no continuations.

Similarly, sizeof is an operator, which doesn't reduce its argument expression to a value.

If we are going to make coding conventions based on pretending that C is a different language in which sizeof is a function, then pretending return is a function is also fair game.

hueving• 11 years ago

He is talking about C. Continuations are irrelevant.

kazinator2• 11 years ago

That point is clearly made in the comment you're replying to, with the additional point that if we are talking about C, then sizeof is an operator, not a function. It doesn't require parentheses, except when its operand is a type expression. No well-considered coding convention requires superfluous parentheses with sizeof, and there are good reasons to ban them.

We should prefer code like:

   type *ptr = malloc(sizeof *ptr);  /* no parens */

   type *ptr = malloc(sizeof (type));

In general it's often better to base sizeof on an ordinary expression rather than a type expression.

If we don't use superfluous parentheses on sizeof, we can then look for sizeof followed by an open parenthesis to look for code where sizeof is applied to a type expression.

  sizeof (type)

means "produce me a size_t value based on some arbitary type, without checking that it's related to anything in the surrounding code". It can be as dangerous as a (type) cast.

anonbanker• 11 years ago

Why shouldn't return be considered a function?

newuser88273• 11 years ago

Scheme has come up with the idea of pretending that an undelimited contination is a function, which is somewhat true-ish... in the degenerate sense of a function with empty domain.

This is fine for Scheme, which is an expression language, so every method of invoking a continuation would, syntactically, be an expression anyway.

In C, which has statements, making return look like an expression is somewhat pointless. It doesn't matter whether C "has" continuations (and it arguably has) or not.

Chathamization• 11 years ago

I first learned that sizeof was an operator when I was confused about how it dealt with arrays compared to functions. After I learned it was an operator and not a function things made sense and were (relatively) consistent again. Several commentators here have given other examples where you will be completely thrown off if you believe that '"sizeof()" really is a function.'

The problem with "lies to children" is that they can pile up to the point where people end up becoming completely confused about what's actually happening. As the internal inconsistencies mount, the "simple" lie starts to become a lot more complex than the "complicated" truth.

tvb• 11 years ago

Makes a good C interview question:

    char  c;
    short h;
    int   i;
    char *s;
    1 = sizeof (char)
    2 = sizeof (short)
    4 = sizeof (int)
    4 = sizeof (float)
    8 = sizeof (double)
    1 = sizeof (c)
    2 = sizeof (h)
    4 = sizeof (i)
    4 = sizeof (s)
    4 = sizeof &c
    1 = sizeof c
    2 = sizeof h
    4 = sizeof i
    4 = sizeof s
    1 = sizeof *s
    4 = sizeof &main
    4 = sizeof (sizeof (i))
    4 = sizeof (sizeof i)
    4 = sizeof sizeof i
    4 = sizeof sizeof sizeof i

from: http://leapsecond.com/tools/size1.c

Humans should think of sizeof() as a function, says Linus Torvalds

Related Stories