[PATCH 4/4] x86: replace global scratch buffer

[Jan Beulich]

On 13.06.2022 15:59, H.J. Lu wrote:
> On Fri, Jun 10, 2022 at 6:36 AM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> With its movement to the stack, and with the subsequent desire to
>> initialize the entire instr_info instances, this has become doubly
>> inefficient. Individual users have better knowledge of how big a buffer
>> they need, and in a number of cases going through an intermediate buffer
>> can be avoided altogether.
>>
>> Having got confirmation that it wasn't intentional to print memory
>> operand displacements with inconsistent style, print_displacement() is
>> now using dis_style_address_offset consistently (eliminating the need
>> for callers to pass in a style).
>>
>> While touching print_operand_value() also convert its "hex" parameter to
>> bool. And while altering (and moving) oappend_immediate(), fold
>> oappend_maybe_intel_with_style() into its only remaining caller. Finally
>> where doing adjustments, use snprintf() in favor of sprintf().
>> ---
>> While doing the conversion I came to notice that print_operand_value()'s
>> "hex" parameter has only ever passed "true" to it. I wonder why this
>> parameter still exists.
>>
> 
> Andrew,
> 
> Do you have follow-up patches to pass "false" to print_operand_value?

I don't think that's related to Andrew's work. Even when looking at plain
2.37 (which I'm sure predates any of his work) I see only 1 ever passed
as the argument. Going very far back (2.16) I see varying arguments. I
therefore wonder whether the parameter simply wasn't cleaned up when the
last party (possibly) passing 0 / false was removed / replaced.

Jan