eal: don't log uninitialized string

  Our Coverity scan pointed out that path[] is never initialized.
The official DPDK Coverity has not reported this so there is
no public CID for it.

Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
Cc: anatoly.burakov@intel.com
Cc: stable@dpdk.org

Signed-off-by: Andrew Boyer <aboyer@pensando.io>
---
 lib/librte_eal/common/eal_common_fbarray.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)
  

> -----Original Message-----
> From: dev <dev-bounces@dpdk.org> On Behalf Of Andrew Boyer
> Sent: Friday, December 11, 2020 5:06 PM
> To: dev@dpdk.org
> Cc: Andrew Boyer <aboyer@pensando.io>; Burakov, Anatoly
> <anatoly.burakov@intel.com>; stable@dpdk.org
> Subject: [dpdk-dev] [PATCH] eal: don't log uninitialized string
> 
> Our Coverity scan pointed out that path[] is never initialized.
> The official DPDK Coverity has not reported this so there is no public CID
> for it.

I double checked and I can confirm that this wasn't picked up by any of the public scans, even though 4 other issues in that file were. So thanks for the fix.
  

On Fri, Dec 11, 2020 at 6:07 PM Andrew Boyer <aboyer@pensando.io> wrote:
>
> Our Coverity scan pointed out that path[] is never initialized.
> The official DPDK Coverity has not reported this so there is
> no public CID for it.
>
> Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
> Cc: anatoly.burakov@intel.com
> Cc: stable@dpdk.org
>
> Signed-off-by: Andrew Boyer <aboyer@pensando.io>
> ---
>  lib/librte_eal/common/eal_common_fbarray.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/lib/librte_eal/common/eal_common_fbarray.c b/lib/librte_eal/common/eal_common_fbarray.c
> index 1220e2bae..6ce89af83 100644
> --- a/lib/librte_eal/common/eal_common_fbarray.c
> +++ b/lib/librte_eal/common/eal_common_fbarray.c
> @@ -83,11 +83,10 @@ get_used_mask(void *data, unsigned int elt_sz, unsigned int len)
>  static int
>  resize_and_map(int fd, void *addr, size_t len)
>  {
> -       char path[PATH_MAX];
>         void *map_addr;
>
>         if (eal_file_truncate(fd, len)) {
> -               RTE_LOG(ERR, EAL, "Cannot truncate %s\n", path);
> +               RTE_LOG(ERR, EAL, "Cannot truncate fd %d\n", fd);

Logging a fd number won't help much, but I guess this was not really
helpful with path[] either :-).
If we keep this log, I would move it to the callers of the functions,
where the filename is available.
  

> On Jan 6, 2021, at 4:35 AM, David Marchand <david.marchand@redhat.com> wrote:
> 
> On Fri, Dec 11, 2020 at 6:07 PM Andrew Boyer <aboyer@pensando.io <mailto:aboyer@pensando.io>> wrote:
>> 
>> Our Coverity scan pointed out that path[] is never initialized.
>> The official DPDK Coverity has not reported this so there is
>> no public CID for it.
>> 
>> Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
>> Cc: anatoly.burakov@intel.com
>> Cc: stable@dpdk.org
>> 
>> Signed-off-by: Andrew Boyer <aboyer@pensando.io>
>> ---
>> lib/librte_eal/common/eal_common_fbarray.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/lib/librte_eal/common/eal_common_fbarray.c b/lib/librte_eal/common/eal_common_fbarray.c
>> index 1220e2bae..6ce89af83 100644
>> --- a/lib/librte_eal/common/eal_common_fbarray.c
>> +++ b/lib/librte_eal/common/eal_common_fbarray.c
>> @@ -83,11 +83,10 @@ get_used_mask(void *data, unsigned int elt_sz, unsigned int len)
>> static int
>> resize_and_map(int fd, void *addr, size_t len)
>> {
>> -       char path[PATH_MAX];
>>        void *map_addr;
>> 
>>        if (eal_file_truncate(fd, len)) {
>> -               RTE_LOG(ERR, EAL, "Cannot truncate %s\n", path);
>> +               RTE_LOG(ERR, EAL, "Cannot truncate fd %d\n", fd);
> 
> Logging a fd number won't help much, but I guess this was not really
> helpful with path[] either :-).
> If we keep this log, I would move it to the callers of the functions,
> where the filename is available.
> 
> 
> -- 
> David Marchand

Can this be taken for 21.02? I realize the log isn’t that useful, but it doesn’t seem worth it (to me at least) to do much more work on it.

-Andrew