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.
> > 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.
--
Joseph S. Myers
jos...@codesourcery.com
