[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: A mismatched type error found
- To: Rroach <2284696125@xxxxxx>
- From: Jan Beulich <jbeulich@xxxxxxxx>
- Date: Mon, 28 Jun 2021 14:06:01 +0200
- Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IjQoxJqvDTIywswmk+AZI3gMAaaJFna4jZzpW+tVyJI=; b=gJYzcupEwHBjuCXSY0SWe/w7v/n2WtXMiImJ2ypihGV88iXlV7bVTIacLmjqCBmjbGW2kerxG1g73kEXWzf1KQbRDJeJCOvatf2q5bSbd2TeKhM/hMrtE1QkPC1Wwo61LwKzMoKTjWA6N8q3V5m2Cmy2S13cBpfIrfaL1nKnlVabgeXwvfRXI2vG0vUP8SUKYCVYBmAhpwDdFxB4Ek5bfTWqInkNR9RfKd3ve9PFOIaTfjli1mcrTZmpXDrjp1DGonz4HIlkHJzBd+U4ZVr+mi1KGcIHkoBNdAbvPwQL7gJkYTbvgrWqsgaAAitfqiHre401rF2TJpHxDLsSO8pPrw==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jVJHOJ0yNQjFut7NNRFVZLidDis+5kSp01pcOKYt7zkO/1IvxXm6gwupBuvclWMvIJPLT1lEGa2CN2oED70Tyq+KqtLPil9h8f9wKC811qbhvXld3vISvypArrBVjT2cfczfXcowGBiTU6s0AmlF6IomFb4bv5RNRs1VRxLUysQs9shIn3+uiZVpSCaA0h+CIbj+kM5GyG1jd0pNCouptQPgxDOhRc7eNsT8klXovFX7nqyH1BVAo2JgvAuAcMXfzcvBPxG5fXz0EeZvoh48EYaIUGpl+Ba8HpK/DCEkbK7Ywv1IYsbHNrrbmLaRk4BJR/5wnQEnRwli63dg1h6Ypg==
- Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
- Cc: xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxxx>
- Delivery-date: Mon, 28 Jun 2021 12:06:14 +0000
- List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
On 26.06.2021 17:36, Rroach wrote:
> Hi, when I look the source code in Xen-4.15 source code, I found a type
> mismatch.
>
>
> In detailed, in xen/arch/x86/msi.c:find_msi_entry, there is a comparison
> between entry->msi_attrib.type and cap_id. However, according to the
> definition, the type appears to be __u8, where is a char variable, and the
> cap_id is defined as int variable, hence it seems to be.a type mismatch.
unsigned char, uint8_t, and alike promote to int when used in an
expression. All callers pass values known to fit in 8 bits. Plus
the hardware field where the ID is coming from is also an 8-bit
one. So while I would welcome a change of the function parameters
from plain int to unsigned int, changing them to uint<NN>_t would
actually make the code worse imo, not the least because of it
then violating ./CODING_STYLE (section "Types"). And using a type
wider than what's needed to hold any valid values in a structure
with perhaps many instances is not a good use of resources.
> Despite this error do not affect system operation by far, it still affect the
> code's quality, as such error could result in potential bugs in the future.
In this case I'm having a hard time seeing any such happen, for
the reasons above.
Jan
|
