Fix the compiling errors in gcc9

[stephenxs]

What I did
Fix the following error.

    orch.cpp: In member function 'ref_resolve_status Orch::resolveFieldRefArray(type_map&, const string&, swss::KeyOpFieldsValuesTuple&, std::vector<long unsigned int>&, std::string&)':
    orch.cpp:609:41: error: 'strlen' argument missing terminating nul [-Werror=stringop-overflow=]
      609 |                     object_name_list += string(&list_item_delimiter);
          |                                         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
    In file included from orch.cpp:6:
    orch.h:25:12: note: referenced argument declared here
       25 | const char list_item_delimiter = ',';
          |            ^~~~~~~~~~~~~~~~~~~
    cc1plus: all warnings being treated as errors

Signed-off-by: Stephen Sun stephens@nvidia.com

Why I did it

How I verified it

Details if related

- Which release branch to backport (provide reason below if selected)

• 201811
• 201911
• 202006
• 202012

[qiluo-msft]

It seems compiler report a true code bug.

const char list_item_delimiter = ',';
object_name_list += string(&list_item_delimiter)

Could you check why you feed a non zero-terminated char* to string ctor?

[qiluo-msft]

As comment

[stephenxs]

It seems compiler report a true code bug.

const char list_item_delimiter = ',';
object_name_list += string(&list_item_delimiter)

Could you check why you feed a non zero-terminated char* to string ctor?

const char list_item_delimiter = ',';
object_name_list += string(&list_item_delimiter, 1);

Need to add a count
Meanwhile, I don’t quite understand why it was not catched by gcc8

[qiluo-msft]

This bug should be detected by either compiler or linter. Could you help explore a general solution to detect other unfound or future occurrences, during build process?

[kcudnik]

change PR name to fix gcc9 warning

[stephenxs]

change PR name to fix gcc9 warning

Done.

[kcudnik]

This bug should be detected by either compiler or linter. Could you help explore a general solution to detect other unfound or future occurrences, during build process?

i actually checked g++ without and with O2 optimization, and if you use & on char constant, it puts data as a single character string which is padded by zeros, and with O2 even aligned with 0x10, but it could be just good practice by gcc, it may not be guaranteed, so warning is helpful in that case

[stephenxs]

This bug should be detected by either compiler or linter. Could you help explore a general solution to detect other unfound or future occurrences, during build process?

i actually checked g++ without and with O2 optimization, and if you use & on char constant, it puts data as a single character string which is padded by zeros, and with O2 even aligned with 0x10, but it could be just good practice by gcc, it may not be guaranteed, so warning is helpful in that case

I'm not sure whether it's related to optimization. I think the default alignment of the types whose size is less than a word length will be the word length of the machine, unless preprecess instructions like #progma pack(1) is used. This means there will be padding bytes after a char variable. But there isn't guarantee that the padding bytes will be zero.