qemu-arm
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] util/hexdump: Convert to take a void pointer argument


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH] util/hexdump: Convert to take a void pointer argument
Date: Sat, 22 Aug 2020 19:57:28 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0


On 8/22/20 6:18 PM, Peter Maydell wrote:
> On Sat, 22 Aug 2020 at 16:05, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:
>> Most uses of qemu_hexdump() do not take an array of char
>> as input, forcing use of cast. Since we can use this
>> helper to dump any kind of buffer, use a pointer to void
>> argument instead.
>>
>> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> 
>> -void qemu_hexdump(const char *buf, FILE *fp, const char *prefix, size_t 
>> size);
>> +void qemu_hexdump(const void *ptr, FILE *fp, const char *prefix, size_t 
>> size);
> 
> Changing the type seems reasonable, but it is still a pointer
> to a buffer, so I think keeping the name 'buf' is more descriptive.

I'll use 'bufptr' so I don't have to modify the function body.

> 
> As an aside, is it just me that finds the order of arguments
> here a bit odd? The pointer to the buffer and the length of
> the buffer are closely related arguments that are widely
> separated in the argument list order, and the FILE* that
> you might expect to come first doesn't. "fp, prefix, buf, size"
> would seem more logical. Not sure it's worth the effort of
> changing, though...

Can do that. I expect this function to eventually disappear,
as there are many efforts to not directly write to stdout/stderr
(this function support generic FILE, but all callers use stdio).

> 
> thanks
> -- PMM
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]