https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118500
Xi Ruoyao <xry111 at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |xry111 at gcc dot gnu.org
--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to Alejandro Colomar from comment #8)
> (In reply to Alejandro Colomar from comment #7)
> > (In reply to Alejandro Colomar from comment #6)
> > > (In reply to David Malcolm from comment #5)
> > > > Thanks for filing this report.
> > >
> > > You're welcome! :-)
> > >
> > > >
> > > > There are (at least) three -fanalyzer issues here:
> > > >
> > > > (a) false positive about leak of 'my_strdup("f,oo")':
> > > > https://godbolt.org/z/rKxhfxWGf
> > > > This is probably due to -fanalyzer getting confused by having both the
> > > > attribute and a function body. I think there's already a report about
> > > > this
> > > > in BZ somewhere.
> > > >
> > > > (b) -fanalyzer doesn't "know" about the behavior of strsep beyond
> > > > "knowing"
> > > > that it doesn't malloc or free anything internally. Hence it doesn't
> > > > know
> > > > that it will advance s to a point within the buffer that's not the start
> > > > (and hence the later "free" is a bug).
> > >
> > > Agree.
> >
> > On the other hand, I think fnalayzer shouldn't get fancy into learning about
> > strsep(3), because then it won't be able to analyze all the other functions
> > that modify a pointer. I think it should instead assume that a T** modifies
> > the pointer value (as opposed to a const T**).
>
> Oops, I meant a T*const*
Or T** having an access(none) or access(read_only) attribute.
