Hi Erich, Thank you for your response. Perhaps we need to align on the definition of a bug. My definition of a bug is an issue that impacts the operation of starlingx software as it is built/used today. I don't consider issues found in code as a result of using a different compiler/tool/build env/distro a bug. I have no issue with the work itself. I just want it to be categorized properly as a feature/enhancement (ex: Support for gcc 8 in prep for multi-OS Support) with tasks that track the extent of the work instead of individual bug stories. Bruce, we can discuss story creation / categorization guidelines in the Wednesday meeting if needed. Thanks, Ghada -----Original Message----- From: Cordoba Malibran, Erich [mailto:erich.cordoba.malibran@intel.com] Sent: Tuesday, August 21, 2018 12:36 PM To: Rowsell, Brent; Khalil, Ghada; starlingx-discuss@lists.starlingx.io Subject: Re: [Starlingx-discuss] Request for clarification related to gcc 8 Hi, I created the two bugs. I'm using gcc 8 as a tool for finding issues that more evident with modern compilers. What I'm doing right now is to compile the C/C++ projects in an isolated environment to perform static analysis. I'm sorry that the title of the issues causes confusion, the two issues are there but gcc 4 doesn't show them. Let me elaborate more on this.
https://storyboard.openstack.org/#!/story/2003498 [Bug] fm-common cannot be built with GCC 8 due to string bound checks
This issue is reported also by Coverity (and I think cppcheck as well). A string is stored without a null terminator. This is a security problem not a gcc 8 specific.
https://storyboard.openstack.org/#!/story/2003497 [Bug] GCC 8 complains of invalid reference null check on fm_common
This one is more tricky. An incorrect usage of a C struct inside C++ code, the difference between a reference and a pointer was confused in the code causing a segfault with optimized code in newer gcc versions. In our path for multi-os support, I think, it's expected to be able to build our projects in different compiler versions. Also, now that we are open source there will be people that will try to build this in clang or even a different architecture having use cases that haven't think about. I believe our code should be robust enough to be portable/flexible without breaking the existing functionality or breaking backwards compatibility with older compilers. I'll update the bugs to clarify the nature of the issues. -Erich On Tue, 2018-08-21 at 15:50 +0000, Rowsell, Brent wrote:
+1
From: Khalil, Ghada [mailto:Ghada.Khalil@windriver.com] Sent: Tuesday, August 21, 2018 11:48 AM To: starlingx-discuss@lists.starlingx.io Subject: [Starlingx-discuss] Request for clarification related to gcc 8
Hi, Can I get clarification/context on these two bug stories that have been recently created? StarlingX does not use gcc 8 currently. What is the activity that is triggering this work? Which sub-team is looking at this?
I wouldn’t really consider these bugs as there was no requirement previously to support this compiler.
If this is part of a new initiative, then we should have a [Feature] story that tracks this initiative with tasks for the different work items required to make the various Starlingx components compliant.
https://storyboard.openstack.org/#!/story/2003497 [Bug] GCC 8 complains of invalid reference null check on fm_common
https://storyboard.openstack.org/#!/story/2003498 [Bug] fm-common cannot be built with GCC 8 due to string bound checks
Thanks, Ghada
Ghada Khalil, Manager, Titanium Cloud, Wind River direct 613.270.2273 skype ghada.khalil.ottawa 350 Terry Fox Drive, Suite 200, Kanata, ON K2K 2W5
_______________________________________________ Starlingx-discuss mailing list Starlingx-discuss@lists.starlingx.io http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss