On Sun, 2022-09-11 at 10:21 +0200, Bernhard Reutner-Fischer wrote:
> On 11 September 2022 10:04:51 CEST, David Malcolm via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>
> > > +++ b/gcc/testsuite/gcc.dg/analyzer/pr106845.c
> > > @@ -0,0 +1,11 @@
> > > +int buf_size;
> > > +
> > > +int
> > > +main (void)
> > > +{
> > > + char buf[buf_size];
> > > +
> > > + __builtin_memset (&buf[1], 0, buf_size);
> > > +
> > > + return 0;
> > > +}
> >
> > ...it took me a moment to realize that the analyzer "sees" that
> > this is
> > "main", and thus buf_size is 0.
>
> Is this a valid assumption?
Not always, but often.
I suppose we could add an option for this.
>
> What if I have a lib (preloaded maybe) that sets it to 42?
...or, say, a C++ ctor for a global object that runs before main, that
has side-effects (see e.g. PR analyzer/97115).
>
> BTW, do we handle -Wl,-init,youre_toast
> where main isn't the entry point?
The analyzer currently has no knowledge of this; it blithely assumes
that no code runs before "main". It also doesn't report about "leaks"
that happen when returning from main, whereas in theory someone could,
say, implement the guts of their program in an atexit handler.
I'm making assumptions in order to try to be more useful for the common
cases, potentially at the expense of the less common ones.
I'm not particularly familiar with the pre-main startup and post-main
shutdown of a process; feel free to file a bug if you want -fanalyzer
to be able to handle this kind of thing (links to pertinent docs would
be helpful!)
Thanks
Dave
>
> Just curious..
> thanks,
>
> >
> > Interestingly, if I rename it to not be "main" (and thus buf_size
> > could
> > be non-zero), we still don't complain:
> > https://godbolt.org/z/PezfTo9Mz
> > Presumably this is a known limitation of the symbolic bounds
> > checking?
> >
> > Thanks
> > Dave
> >
>
