>> I'm writing a manpage for a library and want to describe a function >> which returns a pointer to a function.
>> extern void (*foo(void (*)(const char *, int)))(const char *, int); [RVP] > After a bit of fiddling with signal.3: Doh! Of course signal(3) is an example. > +.ds cm \f[R],\f[] > .Ft void \*(lp* > -.Fn signal "int sig" "void \*(lp*func\*(rp\*(lpint\*(rp\*(rp\*(rp\*(lpint" > +.Fn foo "void \*(lp*\*(rp\*(lpconst char *\*(cm int\*(rp\*(rp\*(rp\*(lpconst > char *\*(cm int" Hm. I'll have to play with it a bit, look at what gets generated for the various versions I care about. This needs thought. [Rhialto] > However I would prefer that it would make a typedef for the signal > handler type, and use that both as argument for signal() and its > return type: it us much more readable. But it also requires dumping yet another typedef into the caller's namespace. I also dislike such typedefs in general, though I'm having trouble codifying what it is that bothers me about them as compared to the typedefs I do use. Now I have two things to think about here. Thank you both! > \X/ There is no AI. There is just someone else's work. --I. Rose Becoming less true, to the extent that weak AI qualifies. Reminds me of "Don't say `the cloud'. Say `someone else's computer'." /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
