>>>> 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
well, you convinced me to use uint32_t instead of u32.
However, This patch will not update other u32(s) to get focus.
I can raise another patch to update parts if necessary.
Cheers,
Lin
