Re: [PATCH v4 5/6] tools: Use new byteswap helper

[Jan Beulich <jbeulich@xxxxxxxx>]

On 24.05.2022 08:52, Lin Liu （刘林） wrote:
>>> On 23.05.2022 11:52, Lin Liu wrote:
>>>>> --- a/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>>>> +++ b/tools/libs/guest/xg_dom_decompress_unsafe_xz.c
>>>>> @@ -34,6 +34,11 @@ static inline u32 le32_to_cpup(const u32 *p)
>>>>>        return cpu_to_le32(*p);
>>>>>  }
>>>>>
>>>>> +static inline u32 le32_to_cpu(u32 val)
>>>>> +{
>>>>> +   return le32_to_cpup((const u32 *)&val);
>>>>> +}
>>>>
>>>> Why the cast? And why not uint32_t?
>>>>
>>>> Jan
>>>
>>> le32_to_cpup has following prototye and definition
>>>
>>> static inline u32 le32_to_cpup(const u32 *p)
>>> {
>>>         return cpu_to_le32(*p);
>>> }
>>>
>>> xg_dom_decompress_unsafe_xz.c redefine and use u32, use u32 to keep 
>>> consistent
>>> typedef uint32_t u32;
>>
>> This answers neither part of my question. For u32 vs uint32_t, please
>> also see ./CODING_STYLE.
> 
> Type cast is unnecessary, will be removed in next version of patch
> CODING_STYLE encourage uint32_t instead of u32,
> However, Current xg_dom_decompress_unsafe_xz.c already use u32 instead of 
> unit32_t, so I
> use u32 to keep censistent, otherwise, the code look strange

Strange or not, that's the only way to phase out certain things without
using gigantic patches / series touching the entire tree at one time.
New code should not use these deprecated (for our purposes) types
anymore. Note how the file you adjust here already has to introduce
these type aliases for things to build. These typedefs really want to
go away, and any new use of those types is another hindrance in doing
so.

Jan