Re: -mdoc: how to handle surrounding types?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> 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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B