On 4/30/19 9:19 AM, Bruce Rogers wrote:
> While investigating link-time-optimization, the compiler flagged this
> case of not handling the error return from scsi_cdb_length(). Handle
> this error case with a trace report.
>
> Signed-off-by: Bruce Rogers <brog...@suse.com>
> ---
> hw/scsi/scsi-disk.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
> index e7e865ab3b..8fbf7512e5 100644
> --- a/hw/scsi/scsi-disk.c
> +++ b/hw/scsi/scsi-disk.c
> @@ -2520,6 +2520,10 @@ static void scsi_disk_new_request_dump(uint32_t lun,
> uint32_t tag, uint8_t *buf)
> int len = scsi_cdb_length(buf);
> char *line_buffer, *p;
>
> + if (len < 0) {
> + trace_scsi_disk_new_request(lun, tag, "bad cdb length");
This is going to print:
"Command: lun=%d tag=0x%x data=bad cdb length"
which is maybe not the best. I'd rather print something more direct, but
it's probably better than actually rolling forward with len = -1.
Then again, this should literally never happen, because scsi_req_new is
parsing the cdb object and already rejecting such cases.
Can you satisfy the compiler by asserting that it is greater than zero?
It ought to be provably true.
--js
> + return;
> + }
> line_buffer = g_malloc(len * 5 + 1);
>
> for (i = 0, p = line_buffer; i < len; i++) {
>
