diff mbox

APEI: pull a signedness check ahead for Coverity's sake

Message ID 57581F9802000078000F2FD6@prv-mh.provo.novell.com (mailing list archive)
State New, archived
Headers show

Commit Message

Jan Beulich June 8, 2016, 11:37 a.m. UTC 
On 64-bit architectures (which is all we care about right now in ACPI
code), the value coming from a __u32 field makes "len" positive anyway,
but since from an abstract pov the tool is right, let's just re-order
things.

Coverity ID: 1204965

Signed-off-by: Jan Beulich <jbeulich@suse.com>
APEI: pull a signedness check ahead for Coverity's sake

On 64-bit architectures (which is all we care about right now in ACPI
code), the value coming from a __u32 field makes "len" positive anyway,
but since from an abstract pov the tool is right, let's just re-order
things.

Coverity ID: 1204965

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -672,9 +672,11 @@ static ssize_t __erst_read(u64 record_id
 	if (rcd_tmp->record_length > buflen)
 		return -ENOBUFS;
 	len = rcd_tmp->record_length;
+	if (len < 0)
+		return -ERANGE;
 	memcpy(record, rcd_tmp, len);
 
-	return len >= 0 ? len : -ERANGE;
+	return len;
 }
 
 /*

Comments

Andrew Cooper June 9, 2016, 2:13 p.m. UTC | #1 
On 08/06/16 12:37, Jan Beulich wrote:
> On 64-bit architectures (which is all we care about right now in ACPI
> code), the value coming from a __u32 field makes "len" positive anyway,
> but since from an abstract pov the tool is right, let's just re-order
> things.
>
> Coverity ID: 1204965
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Julien Grall June 9, 2016, 2:24 p.m. UTC | #2 
Hi Jan,

On 08/06/16 12:37, Jan Beulich wrote:
> On 64-bit architectures (which is all we care about right now in ACPI
> code), the value coming from a __u32 field makes "len" positive anyway,
> but since from an abstract pov the tool is right, let's just re-order
> things.

All the usage of len are unsigned, so why do we want to keep len signed?

Regards,
Jan Beulich June 9, 2016, 3:08 p.m. UTC | #3 
>>> On 09.06.16 at 16:24, <julien.grall@arm.com> wrote:
> On 08/06/16 12:37, Jan Beulich wrote:
>> On 64-bit architectures (which is all we care about right now in ACPI
>> code), the value coming from a __u32 field makes "len" positive anyway,
>> but since from an abstract pov the tool is right, let's just re-order
>> things.
> 
> All the usage of len are unsigned, so why do we want to keep len signed?

Because it serves as the return value of the function, and the
function's return type is signed. Also note how the change makes
the code correct even for 32-bit architectures, even if we don't
care about such in ACPI code right now.

Jan
diff mbox

Patch

--- a/xen/drivers/acpi/apei/erst.c
+++ b/xen/drivers/acpi/apei/erst.c
@@ -672,9 +672,11 @@  static ssize_t __erst_read(u64 record_id
 	if (rcd_tmp->record_length > buflen)
 		return -ENOBUFS;
 	len = rcd_tmp->record_length;
+	if (len < 0)
+		return -ERANGE;
 	memcpy(record, rcd_tmp, len);
 
-	return len >= 0 ? len : -ERANGE;
+	return len;
 }
 
 /*