qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] hw/iommu: Fix problems reported by Coverity sca


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH] hw/iommu: Fix problems reported by Coverity scan
Date: Tue, 04 Oct 2016 10:06:39 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Stefan Weil <address@hidden> writes:

> Hi,
>
> On 10/01/16 17:57, David Kiarie wrote:
>> Signed-off-by: David Kiarie <address@hidden>
>> ---
>>  hw/i386/amd_iommu.c | 12 ++++++++----
>>  1 file changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/hw/i386/amd_iommu.c b/hw/i386/amd_iommu.c
>> index 023de52..815d45f 100644
>> --- a/hw/i386/amd_iommu.c
>> +++ b/hw/i386/amd_iommu.c
>> @@ -144,7 +144,7 @@ static void amdvi_assign_andq(AMDVIState *s, hwaddr 
>> addr, uint64_t val)
>>  static void amdvi_generate_msi_interrupt(AMDVIState *s)
>>  {
>>      MSIMessage msg;
>> -    MemTxAttrs attrs;
>> +    MemTxAttrs attrs = {0, 0};
>>
>>      attrs.requester_id = pci_requester_id(&s->pci.dev);
>>
>> @@ -185,7 +185,7 @@ static void amdvi_setevent_bits(uint64_t *buffer, 
>> uint64_t value, int start,
>>                                  int length)
>>  {
>>      int index = start / 64, bitpos = start % 64;
>> -    uint64_t mask = ((1 << length) - 1) << bitpos;
>> +    uint64_t mask = ((1UL << length) - 1) << bitpos;
>>      buffer[index] &= ~mask;
>>      buffer[index] |= (value << bitpos) & mask;
>>  }
>> @@ -334,7 +334,7 @@ static void amdvi_update_iotlb(AMDVIState *s, uint16_t 
>> devid,
>>                                 uint16_t domid)
>>  {
>>      AMDVIIOTLBEntry *entry = g_malloc(sizeof(*entry));
>> -    uint64_t *key = g_malloc(sizeof(key));
>> +    uint64_t *key = g_malloc(sizeof(*key));
>
> I suggest using g_new(uint64_t, 1) here.

Either way is fine.

g_new(T, 1) is clearly superior to g_malloc(sizeof(T)), because it's
terser, and yields a more useful type.

v = g_new(T, 1) vs. v = g_malloc(sizeof(*v)) is less clear.  The g_new()
is more tightly typed, but the typing doesn't buy much here.  The
g_malloc() is idiomatic usage.  Matter of taste.

[...]



reply via email to

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