This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix bogus function cast warning for functions with common arg subset
On 02/23/2018 01:32 PM, Siddhesh Poyarekar wrote:
On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote:
Casting the address of a function that takes one or more arguments
to one that takes fewer is unsafe because when the pointer is used
to call the function the extra arguments have indeterminate values.
(This is also why void(*)(void) as a wildcard was a poor choice:
because it's only safe when it's an exact match.)
Casting in the opposite direction (fewer arguments to more) can
also lead to bugs under ABIs where the callee is responsible for
restoring the frame pointer.
I completely agree about the safety aspect of it, but my argument is
about user experience, not safety. We are after all talking about
explicit casts, i.e. cast decisions that users have consciously made.
I agree. That was also my first comment on the feature when
it was first proposed:
https://gcc.gnu.org/ml/gcc-patches/2017-10/msg00275.html
The intent behind the warning is to help find instances of these
conversions that are unsafe and to drive improvements to code and
get it to adopt a single common wildcard. The current choice
isn't ideal but expanding it even further would compromise
the goal of the warning even more.
While varargs may solve a lot of these problems, the best viable
solution or cases where such casts are necessary seems to be to switch
off the warning, which kinda defeats the goal anyway. IMO we're better
off making the warnings as less intrusive as possible to begin with and
then gradually make them more aggressive.
In my mind that would be a perfectly reasonable approach.
A variation on it might be to leave a new warning disabled
in the first release, then include it in -Wextra the next
release, and finally put it in -Wall.
Unfortunately, in reality this rarely happens. Most warnings
stay wherever they land when they're first added and only few
are ever tightened up. Most also stay the same for many
releases. (IME, it's not a fun or glamorous job to do the
work it takes to turn on a disabled warning, or to tighten
up an existing one and deal with the fallout.)
Martin