[ On , June 26, 2002 at 09:11:06 (+0200), Eric Jacoboni wrote: ]
> Subject: Re: Curious SYNOPSIS in signal(3)
>
> >>>>> "Greywolf" == Greywolf  <greywolf@starwolf.com> writes:
> 
> Greywolf> # it could be nice to add it in the synopsis as an
> Greywolf> alternative for the # basic syntax.
> 
> Greywolf> How is typedef'ing it clearer than inlining it?
> 
> Trust me: for some people, it is. I teach system programmation and i
> see every year that students prefer this notation.

Be careful that you understand why they prefer the typedef'ed notation.
I suspect it is only because it's easier to read and easier to type.  I
doubt they have a deeper understanding -- indeed I'll bet they have a
much more superficial understanding.  Any of your students who's not
learned to use either notation equally proficiently will likely fail any
C interview test I'd give them because I'll trick them with typedef
names they don't know and then turn around and require them to write
declarations for functions returning a pointer to a function that
doesn't give them enough memory clues to remember the signal()
declaration and to simply regurgitate it by rote.


I just realised though that the prototype declaration given in the
manual page is wrong (yesterday when I looked at it I just though that
maybe ANSI/ISO syntax was worse than I  had thought, but now when I look
at the actual headers I discover the correct declaration isn't quite so
stupid looking:

	void (*signal(int signo, void (*func)(int)))(int);

(The semicolon statement terminator appearing before the actual end of
the statment had me really worried there for a little while, and it's
almost the pathalogical case for such a declaration so I had to look it
up myself!)

Now to see if mdoc(7) will allow an easy fix to the mess in signal(3)...

This is the best hack I can do, so I'll send-pr it:

.\" we can not write decls using function pointers with .Fn yet
.Ft void
.br
.Ic ( *signal (
.Ft int
.Fa signo ,
.Ft void
.Pq Fa *func
.Po
.Vt int
.Pc
.No ))
.Po
.Vt int
.Pc
.No ;


-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods@acm.org>;  <g.a.woods@ieee.org>;  <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>