On Thu, Oct 25, 2018 at 05:53:22AM -0500, Martin Liška wrote: > On 10/24/18 7:48 PM, Martin Sebor wrote: > > On 10/24/2018 03:52 AM, Martin Liška wrote: > >> On 10/23/18 6:31 PM, Martin Sebor wrote: > >>> On 10/22/2018 07:05 AM, Martin Liška wrote: > >>>> On 10/16/18 6:57 PM, James Greenhalgh wrote: > >>>>> On Mon, Oct 08, 2018 at 05:34:52AM -0500, Martin Liška wrote: > >>>>>> Hi. > >>>>>> > >>>>>> I'm attaching updated version of the patch. > >>>>> > >>>>> Can't say I'm thrilled by the allocation/free (aarch64_parse_extension > >>>>> allocates, everyone else has to free) responsibilities here. > >>>> > >>>> Agreed. > >>>> > >>>>> > >>>>> If you can clean that up I'd be much happier. The overall patch is OK. > >>>> > >>>> I rewrote that to use std::string, hope it's improvement? > >>> > >> > >> Hi Martin > >> > >>> If STR below is not nul-terminated the std::string ctor is not > >>> safe. > >> > >> Appreciate the help. The string should be null-terminated, it either comes > >> from GCC command line or it's a valid of an attribute in source code. > >> > >> If it is nul-terminated but LEN is equal to its length > >>> then the nul assignment should be unnecessary. If LEN is less > >>> than its length and the goal is to truncate the string then > >>> calling resize() would be the right way to do it. Otherwise, > >>> assigning a nul to an element into the middle won't truncate > >>> (it will leave the remaining elements there). (This may not > >>> matter if the string isn't appended to after that.) > >> > >> That's new for me, I reworked the patch to use resize. Btw. it sounds > >> a candidate for a new warning ;) ? Must be quite common mistake? > > > > I should have also mentioned that there is constructor that > > takes a pointer and a count: > > > > *invalid_extension = std::string (str, len); > > > > That would be even better than calling resize (sorry about that). > > That's fine, I'm sending updated patch. Tested just locally as cross compiler > in valgind. > > > > > There are lots of opportunities for warnings about misuses of > > the standard library. I think we need to first solve > > the -Wno-system-headers problem (which disables most warnings > > for standard library headers). > > I see!
OK. Thanks, James