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
