On Thu, 30 May 2019, Alex Henrie wrote: > In Wine we need a way to (without warnings) put ms_hook_prologue into > a macro that is applied to functions, function pointers, and function > pointer typedefs. It sounds like you're saying that you will not > accept a patch that silences or splits off warnings about using > ms_hook_prologue with function pointers and function pointer typedefs. > So how do you think Wine's problem should be solved?
By actually implementing the required semantics, not by silencing warnings that say you're using an attribute in a location for which no semantics for that attribute are known. 1. An attribute appertaining to a function pointer (an object whose type is pointer to function) is something different from an attribute appertaining to the type of the pointed-to function. For example, the "section" attribute appertains to declarations. If you apply it to the declaration of a function, it puts that function in that section. If you apply it to the declaration of an object whose type is pointer to function, it puts that object in that section (it does not say what section the pointed-to function is in). 2. The "Attribute Syntax" section in the manual describes how to determine to what construct an attribute in the GNU syntax appertains. Please note that this is *not* always the same construct to which a C++ / C2x attribute in the same place would appertain (I might look at C2x attribute implementation and other C2x features implementation around August/September, not before then). You should first be familiar with how the C standard defines the syntax for declarators and their corresponding types, in order to follow the extensions for attributes included in declarators. 3. There are certain cases where GCC is deliberately lax about attributes being in the syntactically correct places, which in particular makes it possible to change an attribute from being a declaration attribute to one on function types without breaking existing source code expecting it to be on function declarations. See the type_required and function_type_required members of struct attribute_spec. Specifying an attribute as being a function type attribute like that means it can be specified in a position where syntactically it should appertain to the declaration of the function pointer object, and be automatically made to appertain to the pointed-to type instead - but that only works if all the code in GCC that looks to see whether some declaration has the attribute present, and acts accordingly, is changed to check for the attribute on the type instead. 4. So suppose you have a particular attribute, currently only accepted on function declarations, that you wish to be accepted on function types. You need to find all the places checking for that attribute on declarations within GCC, to implement its semantics, and change them (a) to check the type of the declaration instead and (b) to work with the appropriate type when there isn't a declaration at all, as for indirect calls. (What's involved in this may depend on whether the code just checks the list of attributes on the declaration, or whether there is some other bit set on the tree that may or may not be present for types at all.) You also need to change the relevant table of attributes to set type_required and function_type_required instead of decl_required. And you need to change the attribute handler accordingly so that it works when given a type rather than a declaration. -- Joseph S. Myers jos...@codesourcery.com