A major design feature of the world's most advanced transportation system, the capacity of the engines on the Space Shuttle, is determined by the size of a horse's arse. In the same way, the world's most advanced computers are limited by the size of our naughty bits.

How are we supposed to be perfect when Nature only gave us 7 registers? By the time the initial solution is half coded, programmers usually wish they'd written the code another way.

The problem is that it's hard to go back and update existing code.

As a trivial example, if you want to rename a function, you have to change the name in the code, the header, and everywhere the function is called. So much time is wasted doing this, yet this is something the computer could be doing. It could nearly be done with a for "*.c *.h" loop and sed.

The problem is that sed doesn't understand C code. It wouldn't have a clue whether the "fred(" in its buffer is the start of a function declaration or a function call. So Step 1 is to write a sed that does understand C code. Tedious but not hard.

Now we can change function names with a "csed --funcname s/oldname/newname/". We can now also change global variable names without touching local variables with "csed --global s/oldname/newname". And update function parameters. And insert function calls in the right places. And delete function calls. Lots of things like that.

If you're modifying library code that other projects use, you can generate csed commands to go along with your updates. The development teams on the other projects can then run those csed commands on their own code (with the "--ask" option of course!) to do the finding, tagging and most of the conversion for the tweaks and updates to your new API.

Sure, it can't do everything automatically, but you can tag csed changes with explanations, possibly even with URLs to relevant documentation, which is inserted into code above the changed functions to indicate which parts need more attention to complete the conversion.

You can also use this same code to grep for what you want. Looking for a macro definition? Type "cgrep --macdef MACRONAME *.h". Want to know where a function is called? How does "cgrep --calls funcname *.c" look? Want to know how much code depends on a function when planning a change? Try "cgrep --calls --descend funcname *.c".

That's quite a lot of useful functionality for embedding a simple C parser into grep and sed. Also allows for a few useful extensions too.

I'm in the middle of coding this now. It's boring, but it's one of the tools I need for what I REALLY want to do. The visualisation part.

More on that topic next entry.