[dpdk-dev] [PATCH v4 03/17] eal: fix wrong strnlen() return value in 32bit icc

Liang, Cunming cunming.liang at intel.com
Tue Feb 10 01:54:17 CET 2015



> -----Original Message-----
> From: Olivier MATZ [mailto:olivier.matz at 6wind.com]
> Sent: Tuesday, February 10, 2015 1:13 AM
> To: Liang, Cunming; dev at dpdk.org
> Subject: Re: [dpdk-dev] [PATCH v4 03/17] eal: fix wrong strnlen() return value in
> 32bit icc
> 
> Hi,
> 
> On 02/09/2015 12:57 PM, Liang, Cunming wrote:
> >>> @@ -469,7 +469,7 @@ eal_parse_lcores(const char *lcores)
> >>>  	/* Remove all blank characters ahead and after */
> >>>  	while (isblank(*lcores))
> >>>  		lcores++;
> >>> -	i = strnlen(lcores, sysconf(_SC_ARG_MAX));
> >>> +	i = strnlen(lcores, PATH_MAX);
> >>>  	while ((i > 0) && isblank(lcores[i - 1]))
> >>>  		i--;
> >>>
> >>>
> >>
> >> I think PATH_MAX is not equivalent to _SC_ARG_MAX.
> >>
> >> But the main question is: why do we need to use strnlen() here instead
> >> of strlen? We can expect that argv[] pointers are always nul-terminated.
> >> Replacing them by strlen() would probably also solve the icc issue.
> > [LCM] You're right, here strlen() also solve icc issue and no risk for argv[].
> > But follows practice suggestion, keeping using those with 'n' function in DPDK is
> not bad.
> > There's additional two reason to keep strnlen and PATH_MAX.
> > 1. PATH_MAX is defined as 4096 which is enough as our input. It doesn't matter
> to be _SC_ARG_MAX or not.
> 
> PATH_MAX is 4096 but it's not related to the maximum argument length.
> 
> > 2. strnlen and PATH_MAX already used in eal_parse_coremask, to keep the
> style consistent in '-l' and '--lcores'.
> 
> I don't think it's a valid argument.
> 
> What is the problem of using strlen()? It looks it solves all the
> issues. Using strlen on valid strings is not a security issue.
[LCM] All right, I buy in your point.
> 
> 
> Regards,
> Olivier


More information about the dev mailing list