C considered dangerous

Posted Aug 30, 2018 12:30 UTC (Thu) by error27 (subscriber, #8346)
In reply to: C considered dangerous by mina86
Parent article: C considered dangerous

In the kernel we use -Wdeclaration-after-statement. It causes a compile error. I introduced one just to show what the warning looks like:

drivers/video/fbdev/sm501fb.c: In function ‘sm501fb_start’:
drivers/video/fbdev/sm501fb.c:1613:2: error: ‘for’ loop initial declarations are only allowed in C99 or C11 mode
for (int k = 0; k < (256 * 3); k++)
^~~

It's an aesthetic preference. https://lkml.org/lkml/2005/12/13/223

One thing that I do is I have "foo->bar" and I want to find out what type it is, so i highlight "bar" then I scroll to the top of the function where "foo" is declared and then I use cscope to jump to the type definition. So it's nice if you kind of know all the variables are declared at the start of the function.

C considered dangerous

Posted Aug 30, 2018 13:43 UTC (Thu) by excors (subscriber, #95769) [Link] (5 responses)

> One thing that I do is I have "foo->bar" and I want to find out what type it is, so i highlight "bar" then I scroll to the top of the function where "foo" is declared and then I use cscope to jump to the type definition.

That sounds like a consequence of not using an IDE that has a decent go-to-declaration feature (which would work for local variables and would properly understand scopes, #includes, macros, etc). And you probably wouldn't even need to look at the original type definition, you could just put the mouse over 'bar' to get a tooltip showing its type, or press the autocomplete key after 'foo->' to see all the members and their types, or use one of several other features.

So it's not only about aesthetic preferences of coding style, it's also about personal choice of editing tool that makes certain styles harder to work with. Since people get very attached to their tools, that seems an impossible conflict to resolve.

C considered dangerous

Posted Aug 30, 2018 14:37 UTC (Thu) by error27 (subscriber, #8346) [Link] (4 responses)

Hm... It turns out that Vim can jump to the declaration. I feel dumb now.

I'm not actually too tied to Vim though and I really don't like cscope. I'm not eager to use KDevelop. What other IDEs are people using on Debian?

C considered dangerous

Posted Aug 31, 2018 7:11 UTC (Fri) by cpitrat (subscriber, #116459) [Link] (3 responses)

Well there's emacs, which supports it too.

Finding the declaration of a variable in Emacs

Posted Sep 3, 2018 22:08 UTC (Mon) by giraffedata (guest, #1954) [Link] (2 responses)

Well there's emacs, which supports it too.

Do tell. How do I point to a local variable use and have Emacs show me where its declaration is?

I know about Etags - But I don't think this is among its functions.

Finding the declaration of a variable in Emacs

Posted Sep 4, 2018 9:34 UTC (Tue) by cpitrat (subscriber, #116459) [Link]

You can use exuberant-ctags. By default, it doesn't include local variables but you can have them with --c-kinds=+l.
To produce file for emacs you also need -e.
So something like:
ctags -e --c-kinds=+l .

Then you can jump to local variable declarations using M-.

Finding the declaration of a variable in Emacs

Posted Sep 7, 2018 10:57 UTC (Fri) by nix (subscriber, #2304) [Link]

You can have Semantic / CEDET show you the definition of the symbol under point after a short delay in the echo area via semantic-idle-local-symbol-highlight-mode, also enableable globally for all buffers, and automatically via adding global-semantic-idle-local-symbol-highlight-mode to semantic-default-submodes.

Doing this for non-local symbols requires CEDET to know how to locate things in your project, which usually happens more or less automatically, particularly if you use etags or GNU GLOBAL.

Searching LKML?

Posted Aug 30, 2018 17:39 UTC (Thu) by marcH (subscriber, #57642) [Link] (4 responses)

> It's an aesthetic preference. https://lkml.org/lkml/2005/12/13/223

Thanks for remembering this and digging out that sub-thread buried in another massive and totally unrelated thread, impressive feat. Now because lkml.org just went down right while I was browsing it, I went and found some alternative locations:

https://marc.info/?l=linux-kernel&m=113449080512291
https://groups.google.com/d/msg/linux.kernel/e0W-NpF0Kr0/... (click on "Topic options->Tree view" below the Subject: to help with the thread dilution issue)

I was once again amazed at how time-consuming it can be to search LKML archive(s) *even when* I already had the complete message information from lkml.org still cached in my browser window!

Eventually I found that (my?) Google groups' default search option was sorting by date which is useless: https://groups.google.com/forum/#!searchin/linux.kernel/%...
Simply asking to "Sort by relevance" fixes it: https://groups.google.com/forum/#!searchin/linux.kernel/%...

Any additional "lkml search education" welcome (and sorry for being off-topic)

Searching LKML?

Posted Sep 4, 2018 11:41 UTC (Tue) by nix (subscriber, #2304) [Link] (3 responses)

I have always used http://lkml.iu.edu/hypermail/linux/kernel/ which is a normal readable mailman-style archive rather than one of these horrible modern ones which makes conversations almost impossible to follow. (Seriously, lkml.org throws away branches of the thread tree that you're just about to read so it can show the tree to you in a 5cm box, and then doesn't visibly offer a 'next in thread' button. What on earth were they thinking?!)

Searching LKML?

Posted Sep 4, 2018 15:00 UTC (Tue) by cortana (subscriber, #24596) [Link]

Where has this been all my life!

Searching LKML?

Posted Sep 4, 2018 17:02 UTC (Tue) by peda (subscriber, #5285) [Link] (1 responses)

While I don't like every aspect of lkml.org, one thing it does is link things together even if time has passed.

E.g. https://lkml.org/lkml/2018/8/30/877 has a link to https://lkml.org/lkml/2018/9/1/41 (and back).

Now, that's only 2 days, but its different months/weeks/whatwever, and that tends to work very badly with archives of the style you prefer, as all threading is broken every so often.

The above two messages in your preferred archive are
http://lkml.iu.edu/hypermail/linux/kernel/1808.3/04944.html
http://lkml.iu.edu/hypermail/linux/kernel/1809.0/00008.html

Please tell me where the thread-next/thread-prev links for these two messages can be found in that archive, because I can't find them, and it really make the whole thing less appealing.

Searching LKML?

Posted Sep 7, 2018 10:58 UTC (Fri) by nix (subscriber, #2304) [Link]

This is the downside :( I wish Mailman next/prev links weren't constrained to within a single month/week like that.

C considered dangerous

Posted Aug 30, 2018 17:58 UTC (Thu) by marcH (subscriber, #57642) [Link]

> It's an aesthetic preference. https://lkml.org/lkml/2005/12/13/223

Well, I'm disappointed: I expected some technical reason and not just a pseudo-"readability" choice. As pointed out there and/or in the stackoverflow discussion, if you can't easily find types in your function then you have a bigger problem because the function is too big in the first place.
In some cases having the type closer to where it's used will actually make the type more obvious.
Afraid people don't look at types often anyway - even less often than they should.

In any case this entire readability debate weighs little compared to uninitialized variables which compilers may not all catch + the noise of compilers reporting false positives. No modern language forces declarations at the top, it's a legacy. Safer languages even tend to force the opposite.