On 2025-03-25 10:30, Jan Beulich wrote:
On 25.03.2025 15:20, Andrew Cooper wrote:
On 25/03/2025 12:51 pm, Jan Beulich wrote:
malloc(), when passed zero size, may return NULL (the behavior is
implementation defined).
More importantly, this is the Musl behaviour, so is how ~most of Gitlab
CI be
On 25.03.2025 15:30, Jan Beulich wrote:
> On 25.03.2025 15:20, Andrew Cooper wrote:
>> On 25/03/2025 12:51 pm, Jan Beulich wrote:
>>> malloc(), when passed zero size, may return NULL (the behavior is
>>> implementation defined).
>>
>> More importantly, this is the Musl behaviour, so is how ~most of
On 25.03.2025 15:20, Andrew Cooper wrote:
> On 25/03/2025 12:51 pm, Jan Beulich wrote:
>> malloc(), when passed zero size, may return NULL (the behavior is
>> implementation defined).
>
> More importantly, this is the Musl behaviour, so is how ~most of Gitlab
> CI behaves.
>
>> Extend the ->gov_
On 25/03/2025 12:51 pm, Jan Beulich wrote:
> malloc(), when passed zero size, may return NULL (the behavior is
> implementation defined).
More importantly, this is the Musl behaviour, so is how ~most of Gitlab
CI behaves.
> Extend the ->gov_num check to the other two
> allocations as well.
I'm
malloc(), when passed zero size, may return NULL (the behavior is
implementation defined). Extend the ->gov_num check to the other two
allocations as well. Don't chance then actually using a NULL in
print_cpufreq_para().
Fixes: 75e06d089d48 ("xenpm: add cpu frequency control interface, through whi
