On 24.05.2022 09:17, 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
>
> well, you convinced me to use uint32_t instead of u32.
> However, This patch will not update other u32(s) to get focus.
Of course, that's fine.
> I can raise another patch to update parts if necessary.
FTAOD: This would certainly be appreciated, but is by no means a
requirement here.
Jan
