[Bug default/20365] suppress apparently harmless restrict type qualification change

[dodji at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20365

--- Comment #5 from dodji at redhat dot com ---
"woodard at redhat dot com" <sourceware-bugzilla@sourceware.org> writes:

> --- Comment #4 from Ben Woodard <woodard at redhat dot com> ---
> This discussion was with Dodji. He pointed out that C++ function mangling and
> the C++ function matching remain the same despite the addition or loss of
> restrict qualifier.

My point was rather that in *C*, the name of the symbol of the function
taking a parameter of a qualified type wouldn't change if the qualifier
is not present.

In C++, though, qualifiers do have an effect on the mangling of the
function symbol name.  So if a qualifier is dropped from the type of a
function parameter, libabigail doesn't even have to compare types to
spot it.  It'll spot it by just looking at functions and variables
symbols names.

There are cases, though, where qualifiers won't matter from an ABI point
of view: it's when we are only looking at the type of a data member, as
opposed to looking at the type of a function parameter.  And this is
what I had in mind.

So, if we can infer that a qualified type is *never* used as a function
parameter type (or as the type of a global variable) in a C++ program
and that the only qualifier changes are seen when looking at data
members then we might want to suppress those qualifier changes.

Mark does have a point, though.  It's that a qualifier change, *is* a
type change.  It's does at least have an impact at the API level.  So,
in general, I think we want to show those changes.  It's only on a
carefully selected small number of instances that we might want to
suppress those changes, IMHO.

Note that today, the only cases where libabigail is dropping qualifiers
today, is on the "const void" type (because I think showing that change
is of little practical value) and on const references, because a
reference is always const.  These two cases were leading to lots of
useless spurious change reports.

-- 
You are receiving this mail because:
You are on the CC list for the bug.