On Thu, 14 Jun 2018, Martin Sebor wrote: > The standard says FILE is a type so I don't think it can > be a macro that expands to something other than a type > named FILE. The spec doesn't prevent programs from > #undef-ing FILE so implementations cannot define it as > one and rely on it staying defined(*). So even if FILE > is a macro, it still (also) has to be an identifier of > a type with that name.
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). > FILE can be a typedef for some other type, but I'm not sure > I see how that creates a problem. fileptr_type_node could > refer to anything at all (even ptr_type_node) initially and > be set to refer to the first file-scope type or typedef > named FILE seen in a translation unit. It shouldn't matter > if that happens to be a type that's unrelated to the stdio > FILE. Is there something I'm missing that makes this approach > not feasible? (If I'm wrong about FILE being a macro to some > unrelated name then that would sink this idea.) 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. -- Joseph S. Myers jos...@codesourcery.com
