About first one.
Yes, C is cool. In the kernel development it is even cooler. Or is it?
If source writing was done with line-based parsing in mind (sed), then crap like [0] wouldn't been existed.
[0] http://lxr.linux.no/linux/scripts/unifdef.c
Also i want to ask, what is more cool, that CPP/GCC triks or [1] C/C++ comments remover?
[1] ftp://flower.upol.cz/dts/Sed0000/hacks/strip-c.sh
So far i didn't find mis-parsing problems. But C and especially C \/ C++ comment soup can have many stupidly hard things to do, that i was fail to envision. This script, BTW, runs faster than most comprehensive one on sed.sf.net: remccoms3
== This leads to question why text parsing is so doomed? ==
Why i type those html tags _here_, why syntax parsers of compiler cannot be used and are not used to high quality and usability syntax highlighting, etc., etc.?
A bit about some issues i wrote here http://article.gmane.org/gmane.linux.usb.general/632. Yet modern academia students, that are doing hard-core(?) kernel programming, like to fix kernel, rather than stupid, useless zoo of syntax highlighters [2].
[2] http://kerneltrap.org/mailarchive/linux-kernel/2008/1/24/603419
As skills go, it's far more useful than "how to trim the trailing whitespace" and the rest of checkpatch.pl-inspired crap that got so popular lately... http://kerneltrap.org/Linux/Decoding_Oops
Yea, Al, whitespace and syntax LKML-guys appeared quite recently. They doing stupid, but yet useful work, work from the wrong end.
I myself, as an amateur newbie, was deeply impressed by appearance of the stuff like[3,4],
[3] http://lxr.linux.no/linux/scripts/cleanfile
3492 bytes
[4] http://lxr.linux.no/linux/scripts/cleanpatch
5132 bytes
I've came up with this one:
ftp://flower.upol.cz/clean-whitespace/clean-whitespace.sh 1024 bytes
Which isn't quite same funcionality, but this meant to be same result[5].
[5] http://mid.gmane.org/20070607230657.GV7266@flower.upol.cz (use subject link to navigate in thread)
Yes, whitespaces were my PITA right from the first patch. Crappy Linux Makefile(s) + GNU Emacs with smart whitespace damage cleanup ==> big diff just after opening the file. I didn't understand, why there is such damage, because before any programming work i've studied The Tool - A Text Editor. It turned out not only technical problem (text editing), but maintaining one: whitespaces in diffs's context are important. Thus, cleanup in one file may break quite many patches elsewhere in people's trees.
-- coming next -- tabstops, `expand` (from clean-whitespace) and more on text parsing -- -o--=O`C #oo'L O <___=E M