This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] tighten up -Wbuiltin-declaration-mismatch (PR 86125)


On 06/15/2018 02:37 PM, Joseph Myers wrote:
On Thu, 14 Jun 2018, Martin Sebor wrote:

You can #undef it and then use FILE yourself as a block-scope identifier.
I don't think it's at all clear that you can #undef it and then use FILE
and expect to get the semantics of the standard type FILE (unlike for
standard functions).

I'm not sure I know what you mean here.  Say we have:

  #include <stdio.h>
  #undef FILE

  void f (void)
  {
    extern FILE *fp;
    fprintf (fp, "");
  }

Are you saying it's not clear that this is well-defined?

Yes.

I'm still not sure I see why but after sleeping on it I've come
to see that FILE being a typedef makes it just as bad as if it
were a macro.  I.e., fprintf can be declared to take the underlying
type instead of FILE* and there's no way for GCC
to know that they're the same:

  struct _StdioFile;
  int fprintf (struct _StdioFile*, const char*, ...);
  typedef struct _StdioFile FILE;

Setting the fileptr_type_node object to point to a different node would
have no effect on the pointers to that particular node nested within
various function types.  You'd need to modify lots of pointers within
those function types, or reconstruct those function types and change the
types of the built-in functions.

Yeah, that sound like a lot of fiddling.  I suppose what
I should have said is that whatever fileptr_type_node pointed
to would be modified in place to refer to the new node.  I.e.,
initialize it to some placeholder kind of an object (a copy
of ptr_type_node like in the C++ FE) and modify the object
once a definition were seen.  Would that work?

Maybe - you'd have to watch out for interactions with type hashing etc.
(modifying a type in place like that is risky because of the possibility
it breaks something that was depending on the contents of the type).

Safer would be to have special cases for lax type comparisons for built-in
functions that are limited to the case where one of the types is
fileptr_type_node and the other is some other pointer-to-object type.

I agree.  I think the warning needs to allow for the first argument
to fprintf et al. to be any arbitrary object pointer type, including
void*.  Let me go with that.

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]