[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-&gt;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




 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.