A few things:

For the record, the code I posted is ugly. The code that was posted before is ugly. It was just a simple example of a specialized way of increasing efficiency in a function that is essentially being called many, many times. (Processing massive amounts of data in an automated way.) Was it a perfect example? No. Is using the full strings a better one? Certainly not.

First thing: If you are using this function to parse syntax from a user then you are using it in the wrong place. So I don't know what the "look wall" argument is all about. The parsing of look should have already been handled and this function shouldn't deal with all of that. (And if it should then it still may be relevant to have a more specialized function somewhere else.)

If you're using this as a highly specialized function (ie, a place where you WERE concerned with efficiency. A big process loop, etc.) there is no reason to pass full strings. The argument against using a single character is the same one that can be argued against with many C functions since the beginning of C programming time. If you're using this function for anything other than automated code or internal places where the programmer is invoking the function call, there's no practical reason to defend passing a full string instead of just a character anyways. (Or just a number in the first place.)

Second of all, here we go again.

Someone always likes to say that register does not work.
It is depreciated, but the example is writing code for a function that in our fictional scenario where it *should be using a register*.

News bulletin: C is depreciated.

In short, It does work. It does speed it up some times. And in the cases it does, it does by a great deal in specialized code, and it does not slow you down by any truly measurable amount when it does not.
The thing you should be concerned with in register variables is the fact you cannot validly take the address location of any register variables.
Not that it matters in this place.

As I said.
"
Since the thread ventured into efficiency land…

This is a merc based derivative. If you want to really be more efficient then go to the aggr_update() function (which even the writer notably and admittedly by the author in the comments above it takes up a great deal of CPU, like 30-50% of all CPU used depending on the mobs in play) and rewrite the system. All this function does is govern aggressive mobs attacking.

In fact, rewrite all of your update polling systems in update.c and make them use an event system. There's a billion snippets out there for C or C++. Or just make them use black/white lists.
"

Things like this artefact are where real gains can be made. This is about half the sand in the dessert.

I'm not sure why you're repeating your previous post verbatim. My point is that, IMHO, talking about this kind of efficiency talk actually isn't really very productive at all here and now. A very simple question was asked, and the straightforward answer that the two functions were basically equivalent was sufficient. You can't (or, at least, shouldn't) expect somebody who's only just starting to learn to code to even start thinking about fixing the update functions…

Sometimes. And other times it can make things slower. But most of the time the keyword is simply ignored, which is fortunate, because most compilers are far better than most programmers at deciding which variables should be stored in the registry.

Seriously, don't use it, particularly not for something like a mud.