Re: [RFC/RFA] add struct parse_context to all command functions

[Joel Brobecker <brobecker@adacore.com>]

> Listening to Tom talk about this I've started to wonder if it's
> necessary... do we have a unified vision on where the global state
> accesses are OK?

I think it will depend on each global. For the current_language and
the input_radix, my goal is to have it used only from the command line
loop that calls the command functions.

> GDB is single threaded.  I anticipate it will remain so.  So, having
> the functions which implement user interface commands read global
> state doesn't seem like a big problem - unlike the expression parser.

I initially thought that it would be OK to have the command functions
that need it access current_language.  But I quickly realized that
this was actually pretty confusing. In order to audit the use of
a current_language, you'd have to check what the function using it
is used for - in particular, make sure that it's used as a command
function. When you have zillions of them spread everywhere in
the code, it's nearly impossible to avoid re-introducing incorrect
uses of the global.

With the approach that I suggest where I add the parameter, I should
be able to never increase the number of references to current_language
(and input_radix). And eventually, I should be able to eliminate them
all, save a couple of places where we know it's OK.

I will wait another couple of days to see how people react, but it
seems at this point that everyone was OK with approach (1), where
I do the transition all in one go. And since Tom was the lead
"questioner" of this change, I'd like to mention that my understanding
is that Tom understands the benefits of adding the extra parameter,
given the above explaination. Tom, please yell if I misunderstood you!
If all is well, I hope to be able to start looking into this sometime
late this week or maybe early next week.

-- 
Joel