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

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

lkml.org

Post reply on HN
Print view View original

131–140 of 140 posts

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

#131

Post by dllthomas »

douche wrote: post #79
xamuel wrote: post #74

Earlier quoted context omitted.

Indentation to identify blocks can break down in things like switch statements: switch( c ) { case 'A': simple_stuff(); break; case 'B': { int temporary_variable = 0; complex_stuff( temporary_variable ); } To me, the advantage of braces on newlines is it makes it extremely easy to tell where blocks start and end---whether you're using your favorite IDE, or reading the code on a blog, or reading the code with "cat". I…

I'm not seeing what the issue here is, besides that this won't compile because of mismatched braces. There is no need to put braces around the contents of a case block. Unless I'm switching on an enum, I rarely find a compelling reason to use switch/case, and there's usually a cleaner way to do it.

"There is no need to put braces around the contents of a case block."

There is here.

In some dialects, you can only declare a variable at the start of a block. From the perspective of the compiler, a "case block" isn't actually a block, just stuff between labels. In order to declare temporary_variable, it may be necessary to put the braces, and it is probably best practice as temporary_variable may otherwise be exposed to later cases (and in C++, a jump over a variable declaration seems to produce an error).

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

#132

Post by krylon »

rwallace wrote: post #86
krylon wrote: post #80

Earlier quoted context omitted.

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: #includ…

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.

I furiously looked at the C standard (C99, anyway) and the documentation to the gcc preprocessor, and have to admit somewhat embarassedly, that you are right. The gcc preprocessor documentation clearly states:

> "If you use the macro name followed by something other than an open-parenthesis (after ignoring any spaces, tabs and comments that follow), it is not a call to the macro, and the preprocessor does not change what you have written."

Thanks for pointing this out to me!

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

#133

Post by gumby »

tmuir wrote: post #124
gumby wrote: post #121

Earlier quoted context omitted.

non-bracket is useful and informative in some cases when used properly (your local style guide takes precedence of course). I would never write if (condition) Foo(x) for the reasons you said. But it can be very useful for a block of "single liners": /* clean up input before passing it to flaky_external_module() */ for(; !isspace(*p); ++p); if (!isdigit(*p)) return INPUT_ERR; for (char *i = p; *i; i++) *i = toupper(*i…

I contend that the brackets always make the code more readable, without exception. It's the normal case. All other variations make you think "something special is happening here, I'm going to have to parse this carefully". The for with a semicolon at the end is easy to overlook. The return in the middle of a function in the middle of a line is easy to overlook. Spacing code out makes it more readable and maintainable…

Well, as I said, these determinations are up to the house style.

I prefer that blocks of code hold together -- think of them as paragraphs. Spacing each sentence of a paragraph out is similarly confusing. But as you say, YMMV.

I find return is_valid(result) ? result : ERR_CODE; common and clear, but perhaps you don't.

I do think that any style guide should forbid while and do..while simply because for has become by far the looping construct of choice in C.

In all cases the point should be correctness and clarity, not showing off that you use unusual language features.

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

#134

Post by tvb »

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

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

#135

Post by barrkel »

JoeAltmaier wrote: post #98
Igglyboo wrote: post #97

Earlier quoted context omitted.

The only problem with this is if/when someone comes along and doesn't notice the missing braces and does if (condition) Foo(x) Bar(x) Expecting Bar(x) to be part of the conditional. This can and does happen.

I hear folks say that, but don't encounter it in the wild. Maybe once in 20 years so far. That construct, reading it just now, just screams out at me "Indentation error!" Anyway it nicely illustrates the need to get braces out of there altogether. The programmers' intent is obvious; let the IDE 'make it so' by emitting braces in the generated code.

I agree with you - I can count the number of times I've seen it in my life on one hand - but ever since the Apple bug, lots of people use it as a club to hit people over the head with, to enforce braces everywhere.

There seems to be a logical error to me. An indentation mistake - something that can be caught trivially by a linter - is not significantly different by nature than any other single-character mistake, like an incorrect constant or misspelled identifier (harder to find with a linter). But because it was at the root of a specific flaw, it's become larger than life.

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

#136

Post by bigtunacan »

tauchunfall wrote: post #118
bigtunacan wrote: post #64

Earlier quoted context omitted.

We would all be better off if semi colons had just been required in JavaScript. The problem is that semi colons are not actually optional in JavaScript. Instead JavaScript use ASI, automatic semi colon invasion, where the compiler attempts to determine where semi colons should go. Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rul…

>Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rules. Are they really complex? This recently released version 4.0.0 of the JavaScript Standard Style [1] suggests to never start a line with "(" or "[". This rule looks even simpler than the rules of operator precedence. [1] https://github.com/feross/standard Update: Now I learned a…

They are complicated enough; and different enough from other languages that they lead to unexpected behaviors. It is just easier to say, "everyone must use semi-colons". Then I can add linting into our build process and reduce risk of bugs.

One quick example is the very contrived example that follows.

return {a:1, b:2}

That is valid JavaScript. It is evaluated as an empty return and an unreachable expression. Probably not what was intended.

I've sent copies of the rules to people and explained them numerous times, but at the end of the day it is more productive to just use them and move on to something else IMHO.

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

#137

Post by newuser88273 »

kazinator wrote: post #103

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

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.

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

#138

Post by MrBuddyCasino »

vidarh wrote: post #43
MrBuddyCasino wrote: post #33

Earlier quoted context omitted.

How do you handle auto-format? If a rules doesn't survive that, its not practical, at least for me.

I've never met an auto-formatter that I haven't hated the output of enough to not use it.

Which ones would that be? The Eclipse one has a million knobs and twiddles, and is bearable in 95% of the time after fiddling with them a lot, which I'm okay with.

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

#139

Post by vidarh »

MrBuddyCasino wrote: post #138
vidarh wrote: post #43

Earlier quoted context omitted.

I've never met an auto-formatter that I haven't hated the output of enough to not use it.

Which ones would that be? The Eclipse one has a million knobs and twiddles, and is bearable in 95% of the time after fiddling with them a lot, which I'm okay with.

I must admit I haven't used Eclipse's auto-formatter because I've never met an IDE that haven't made me want to kill myself, and Eclipse is at the top of the list of IDE's I have never been able to stand more for than 5 minutes.

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

#140

Post by lazzlazzlazz »

noselasd wrote: post #13
lazzlazzlazz wrote: post #3

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

It's an unary operator, with 2 forms: sizeof(type) or 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.

That's a language design choice - not a conceptual argument.
Post reply on HN