While registering a new command, jim accepts a pointer to command's
private data that will be accessible during the command execution.
Today openocd is not consistent and passes different private data
depending on the command, and then even overwrites it:
- "simple" commands (.handler) are registered with their own
struct command pointer as command private data;
- "native" commands (.jim_handler) at root level are registered
with NULL command private data;
- "native" commands (.jim_handler) not at root level are
registered with the struct command pointer of their root command
as command private data but, when executed, the command private
data is overwritten by the value in field jim_handler_data taken
from their struct command.
Uniform the usage of command private data by always set it to the
struct command pointer while registering the new commands.
Note: for multi-word commands only the root command is registered,
so command private data will be set to the struct command of the
root command. This will change later in this series when the full-
name of the command will be registered.
Don't overwrite the command private data, but let the commands that
needs jim_handler_data to get it directly through struct command.
For sake of uniformity, let function command_set_handler_data() to
set the field jim_handler_data also for "group" commands, even if
such value will not be used.
Now Jim_CmdPrivData() always returns a struct command pointer, so
wrap it in the inline function jim_to_command() to gain compile
time check on the returned type.
While there, uniform the code to use the macro Jim_CmdPrivData()
to access the command's private data pointer.
Change-Id: Idba16242ba1f6769341b4030a49cdf35a5278695
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: http://openocd.zylin.com/5664
Tested-by: jenkins
Reviewed-by: Oleksij Rempel <linux@rempel-privat.de>
a510c8e23c