From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Subject: Re: [PATCH v3] app/proc-info: fix port mask parse issue
Date: Wed, 14 Nov 2018 10:39:51 +0000
Message-ID: <c87c5a8a-5b7a-6fbf-8ead-279647d6de13@intel.com>
References: <1541571009-12396-1-git-send-email-han.li1@zte.com.cn>
 <3847235.2WWUCME0sW@xps>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dev@dpdk.org, reshma.pattan@intel.com
To: Thomas Monjalon <thomas@monjalon.net>, Li Han <han.li1@zte.com.cn>
Return-path: <dev-bounces@dpdk.org>
Received: from mga01.intel.com (mga01.intel.com [192.55.52.88])
 by dpdk.org (Postfix) with ESMTP id B46CC5B12
 for <dev@dpdk.org>; Wed, 14 Nov 2018 11:39:54 +0100 (CET)
In-Reply-To: <3847235.2WWUCME0sW@xps>
Content-Language: en-US
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

On 14-Nov-18 3:10 AM, Thomas Monjalon wrote:
> Hi,
> 
> 07/11/2018 07:10, Li Han:
>> parse_portmask return type is int,but global variable
>> "enabled_port_mask" type is uint32_t.so in proc_info_parse_args
>> function,when parse_portmask return -1,"enabled_port_mask" will
>> get a huge value and "if (enabled_port_mask == 0)" will never happen.
>>
>> Fixes: 22561383ea17 ("app: replace dump_cfg by proc_info")
>> Signed-off-by: Li Han <han.li1@zte.com.cn>
> [...]
>> -static uint32_t enabled_port_mask;
>> +static uint64_t enabled_port_mask;
> [...]
>> -static int
>> +static unsigned long
>>   parse_portmask(const char *portmask)
> 
> On one side, you use uint64_t, on the other side, you use unsigned long.
> I don't understand the logic behind.
> 

Not only there's no logic, it'll actually fail on 32-bit, since 64-bit 
int is unsigned long long there :)

-- 
Thanks,
Anatoly