Moving the kernel to modern C [LWN.net]

Moving the kernel to modern C

Posted Feb 25, 2022 19:53 UTC (Fri) by marcH (subscriber, #57642)
In reply to: Moving the kernel to modern C by ballombe
Parent article: Moving the kernel to modern C

> > Please no! That's the most horrible thing I hate in modern C.

You meant: in _any_ vaguely modern language. What rock have you been living under?

> Usually, when it is used, it is a sign the function is too large and should be split, which would resolve the scoping issue.

Exactly. If you can't find a variable declaration then the function is simply too long.

Of course with https://en.wikipedia.org/wiki/Type_inference (1958) you don't even need to declarations _at all_ but again, let's not get carried away and scare ancient species...

to post comments

Moving the kernel to modern C

Posted Feb 25, 2022 20:53 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (8 responses)

If I can't find the variable declaration, I'm using generic or weakly language-aware editing tools instead of strongly language-aware editing tools.

Moving the kernel to modern C

Posted Feb 26, 2022 14:07 UTC (Sat) by Wol (subscriber, #4433) [Link] (7 responses)

Are you telling me strongly language-aware editing tools can find non-existing declarations?

Okay, I find the lack of declarations ON OCCASION a complete pain, but don't blame the tool if the language doesn't require declarations. There's plenty of languages like that out there ...

(Which is why I tend to use Option Explicit in VB, or -DCLVAR in FORTRAN, etc etc.)

Cheers,
Wol

Moving the kernel to modern C

Posted Feb 26, 2022 14:55 UTC (Sat) by mpr22 (subscriber, #60784) [Link]

> There's plenty of languages like that out there ...

There are, but in the small handful that I use (or have used in the past), I have never written a program where losing track of where I first initialized a variable would be a serious concern.

Moving the kernel to modern C

Posted Feb 26, 2022 15:19 UTC (Sat) by nix (subscriber, #2304) [Link]

> Are you telling me strongly language-aware editing tools can find non-existing declarations?

Well, no, but they can tell you what types the compiler has inferred for those variables (assuming the program is currently syntactically valid enough to do so, which in my experience is usually true if you're doing maintenance rather than writing a new function: if you're writing a new function, I hope you already know what types the variables you're using in your new code are. :) )

Moving the kernel to modern C

Posted Feb 26, 2022 22:10 UTC (Sat) by camhusmj38 (subscriber, #99234) [Link] (4 responses)

Type Inference is not the same as no declaration. Type Inference just means types don’t have to be explicitly stated where the compiler can infer it from the expression used to initialise the variable.

Moving the kernel to modern C

Posted Feb 27, 2022 16:04 UTC (Sun) by marcH (subscriber, #57642) [Link] (3 responses)

Why would be the purpose of a declaration without an explicit type?

How would a typeless declaration help the people in this thread who complain about not finding declarations? If not the type, what else are they looking for?

Moving the kernel to modern C

Posted Feb 27, 2022 18:55 UTC (Sun) by camhusmj38 (subscriber, #99234) [Link] (1 responses)

The declaration has a type - it’s inferred from the initialiser. It’s really only appropriate with local variables.

Moving the kernel to modern C

Posted Feb 27, 2022 20:49 UTC (Sun) by marcH (subscriber, #57642) [Link]

I see nothing factually wrong in your last two comments above but I really don't understand why they're posted as replies to mine. I'm afraid you're misunderstanding my points and questions.

Moving the kernel to modern C

Posted Feb 27, 2022 19:06 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

In Rust, it can move the lifetime of a variable around. So if I have some code that needs to live for the outer scope, but is only "known" in some nested place, I can use `let somename;` on a block in the right place, initialize it where the data is available, and continue on. I've used this before to keep a string alive long enough for a context where it may have been either allocated (and therefore need a place to hang its destructor) or came from some other string that lived longer than the function anyways.