Re: Surprising behavior of suppress_type drop = yes

[Mark Wielaard <mark@klomp.org>]

Hi Dodji,

On Thu, 2020-04-09 at 15:52 +0200, Dodji Seketeli wrote:
> I am attaching below the libfoo.supp suppression file I used.
> Actually, there are no '"' delimitation character either.
> 
> [...]
> 
> > It doesn't seem to change anything for my example.  I assume it
> > does for you?
> 
> Yes, sorry, it's my fault.  I hope with suppression file below it
> gets better.

It does! Thanks. Now it looks like expected.

> > > > Or can we have a "drop mode" that treats handles to dropped
> > > > types a
> > > > simple void pointers instead?
> > > 
> > > I think what you'd need, really, is a combination of:
> > > 
> > >     1/ a new --header-files{1,2} option
> > >     2/ an "opaque = yes" attribute in the suppression
> > > specification.
> > > 
> > > I think either 1/ or 2/ should work, but it'd be nice to have
> > > both.
> > > 
> > > If you think that suggession holds water, then we should probably
> > > file a
> > > bug to add this new feature.
> > 
> > Why not fix the default?
> 
> I am not sure what you mean by default.
> 
> "drop = yes" in the [suppress_type] section of a suppression
> specification is not meant to be the same feature as
> --header-files{1,2}.
> 
> drop = yes really drops *all* types that match the suppression
> specification.  Those types disappear completement from the internal
> representation.  This can be useful to aggressively reduce the size
> of
> the internal representation.
> 
> --header-files{1,2} generates a suppression specification that drop
> all
> types that are not defined in header files, but, for class/struct/
> types, it does something different.  Rather than just droping those
> struct/class types from the internal representation, it replaces them
> by
> a (forward) declaration -- as opposed to the full type
> definition.  So a
> pointer to that declaration becomes a pointer to an opaque type, in
> practise.
> 
> These two features are useful to people in different use cases.

I see. But I find the dropping of function parameters odd. It means you
will be unable to see some issues when functions change an argument
with a dropped type. Say you have an function:

alert (Foobar *f, char *msg);

Where Foobar is an opaque (dropped) type. And you realize the alert
doesn't really depend on the given Foobar. So you remove it.

alert (char *msg);

That is an incompatible abi change, you won't be able to spot with the
current behavior of drop = yes.

I had expected that drop = yes would do what --headers-dir --drop-
private-types did and not remove the arguments that (indirectly)
reference the type got dropped too.

> If your question is "how to do exactly what --headers-files{1,2} does
> using suppression specfications", then the official answer today is
> "you can't".

OK. I don't particularly want to do it through a suppression
specification, but currently cannot easily do it through the command
line because I need something like --header-file because my public and
private headers are in the same dir (as the sources). And abidw doesn't
take --drop-private-types.

I'll sent patches to implement that.

Thanks,

Mark