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


Reply via email to