[Starlingx-discuss] Request for clarification related to gcc 8

Eslimi, Dariush Dariush.Eslimi at windriver.com
Tue Aug 21 19:11:07 UTC 2018


Bruce I agree on the first on that is a bug, regardless of the tool it is a security issue and should be triaged and assigned a priority to be fixed, but the second one is only an issue if you try to use gcc 8, under currently supported build process that is not a bug.
So the second one would be better tracked under a feature that tracks all issues that need to be resolved to support the new compiler.

Dariush

-----Original Message-----
From: Jones, Bruce E [mailto:bruce.e.jones at intel.com] 
Sent: August-21-18 2:52 PM
To: Khalil, Ghada; Cordoba Malibran, Erich; Rowsell, Brent; starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Request for clarification related to gcc 8

Ghada wrote:
> 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.

Code errors like this are bugs that have not yet been found.  That may make them less important but it doesn't mean they are not bugs.  

Our goal should be to make our code as clean and bug free as possible.  

         brucej

-----Original Message-----
From: Khalil, Ghada [mailto:Ghada.Khalil at windriver.com]
Sent: Tuesday, August 21, 2018 10:48 AM
To: Cordoba Malibran, Erich <erich.cordoba.malibran at intel.com>; Rowsell, Brent <Brent.Rowsell at windriver.com>; starlingx-discuss at lists.starlingx.io
Subject: Re: [Starlingx-discuss] Request for clarification related to gcc 8

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 at intel.com]
Sent: Tuesday, August 21, 2018 12:36 PM
To: Rowsell, Brent; Khalil, Ghada; starlingx-discuss at 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 at windriver.com]
> Sent: Tuesday, August 21, 2018 11:48 AM
> To: starlingx-discuss at 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 at lists.starlingx.io
> http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss
_______________________________________________
Starlingx-discuss mailing list
Starlingx-discuss at lists.starlingx.io
http://lists.starlingx.io/cgi-bin/mailman/listinfo/starlingx-discuss


More information about the Starlingx-discuss mailing list