This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125)
On 06/14/2018 01:33 PM, Joseph Myers wrote:
On Thu, 14 Jun 2018, Martin Sebor wrote:
There's a comment in the code about the weak checking being
deliberate (the word harmless here suggests the author may
not have fully appreciated all the conversions it allows):
/* Accept harmless mismatch in function types.
This is for the ffs and fprintf builtins. */
If you concerned about the change causing trouble in this
context, then if there are legacy systems that GCC still
supports that declare standard functions with non-standard
signatures they should be taken into consideration somehow.
For fprintf and various related functions, you need to allow for the
built-in function being declared without the compiler knowing what the
FILE type will end up being a typedef for - i.e., you can't avoid having
some special case somewhere for built-in functions using
fileptr_type_node, if nothing else.
Hmm, I thought fileptr_type_node was a node for FILE*, but it's
actually the same as ptr_type_node, i.e., void*, so the built-in
fprintf expects a void* argument (and declaring it to take a FILE*
triggers the new warning). That seems odd. What purpose does it
serve? (AFAICS, it's not used anywhere except jit).
I would expect fileptr_type_node to be set to correspond to
FILE* once FILE is declared. Why is that not done?
For other functions, the issue as per
<https://gcc.gnu.org/ml/gcc-patches/2001-04/msg00435.html> may well have
been bad types in some system headers such as "char *sprintf();". To the
extent that any such systems with bad (but ABI-compatible) types for some
functions in system headers are still supported as GCC targets, I think it
would be reasonable to say that fixincludes, not extra laxity in built-in
function types, is the way to deal with the bad types in headers.
Sounds good.
Martin