Those are function pointers. Your parent was referring to the function type. Per ISO/IEC 9899:TC3:
A function type describes a function with specified return type. A function type is characterized by its return type and the number and types of its parameters. A function type is said to be derived from its return type, and if its return type is T , the function type is sometimes called ‘‘function returning T’’. The construction of a function type from a return type is called ‘‘function type derivation’’.
[If you've ever been under the impression that "real" people use the actual ISO text, disabuse yourself of that notion, ISO takes ages to turn the same exact words into an official branded document, then charges $$$ for a PDF, ain't nobody got time or money for that]
I can't tell you what they intended by TC3. It might be a typo or it might be some way to refer to a specific draft or a section within that draft. I doubt this particular section changes frequently so I wouldn't worry about it.
OK? But like, why a version of C99? So neither C89, which I could understand as this idea that it has "always" been that way, but also not C23, which is the current standard.
It sounds like this text is essentially the same in C23, maybe moved around a bit.
Would also be my default goto version. Reasonable old to be supported everywhere, some quality of live improvements like initialization syntax, without all the modern fluff.
C99 added a few convenience features over C89, in particular the ability to declare variables everywhere in a function, so it is (or was) a common target.
I regularly use that in C, to make sure a function matches an abstract interface. Sure, that often ends up in a function pointer, but not always and when I declare the type signature, it isn't yet a function pointer.
> but not define
I think that is because the type signature only contains the types, but no parameter names, which are required for a definition. This is arbitrary, since for data types, the member names are part of the type. It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions. Or you would make names also mandatory for function declarations.
> It sounds totally fixable, but then you either have two types of function types, one where all parameter names are qualified and one where they aren't and only could use the former for function definitions
Making the names part of the type would be a bit weird, although we have seen stranger things. The biggest problem is that it would be a breaking change at least in C++.
> The biggest problem is that it would be a breaking change at least in C++.
Exactly, I believe that to be the case in C as well. In C23 the rules for types to be considered compatible were actually relaxed, so this proposal wouldn't make any sense. It would be a useless breaking change for no gain, other than a bit less typing and maybe feeding some language layers, so there is really no reason to do that. It actually makes the code less clear, since you now need to always lookup the type definition, which would be against C's philosophy.