From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:55040)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZEvbb-0006zl-PH
	for qemu-devel@nongnu.org; Tue, 14 Jul 2015 04:30:26 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pbonzini@redhat.com>) id 1ZEvbW-0002K9-2A
	for qemu-devel@nongnu.org; Tue, 14 Jul 2015 04:30:23 -0400
References: <1436815589-19194-1-git-send-email-jsnow@redhat.com>
	<CAFEAcA_hE0eepawDhF2DBidhd6iXvOx2f6w11+gFk-nh3Ju1XQ@mail.gmail.com>
	<55A41474.8000004@redhat.com>
From: Paolo Bonzini <pbonzini@redhat.com>
Message-ID: <55A4C890.70402@redhat.com>
Date: Tue, 14 Jul 2015 10:30:08 +0200
MIME-Version: 1.0
In-Reply-To: <55A41474.8000004@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH] ide: coverity touchups
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: John Snow <jsnow@redhat.com>, Peter Maydell <peter.maydell@linaro.org>
Cc: QEMU Trivial <qemu-trivial@nongnu.org>, Michael Tokarev <mjt@tls.msk.ru>, QEMU Developers <qemu-devel@nongnu.org>, Qemu-block <qemu-block@nongnu.org>



On 13/07/2015 21:41, John Snow wrote:
>>> >> s->ports should never exceed 32, but coverity doesn't know that.
>>> >> ncq_tfs->sector_count should also never exceed 64K.
>> > 
>> > Personally I tend to mark that kind of thing as a false
>> > positive in the coverity UI and move on...
>> > 
>> > -- PMM
>> > 
> Either way; Paolo pinged me about the NCQ one so I figured I'd just do it.

Yeah, neither is particularly optimal.  Every now and then (a couple
years, say) you do have to re-evaluate false positives, so it's better
to fix them if possible.  On the other hand the code is uglier.

Let's ignore these in Coverity---with a triaging comment there about why
they are false positives.

Paolo