flaps@dgp.toronto.edu (Alan J Rosenthal) (04/05/88)
Discussing signal handlers, Karl Heuer wrote something like >static void catch(int signo) { gotcha = 1; } Someone else corrected him and said it should be >static void catch(int signo, code; struct sigcontext *scp) { gotcha = 1; } and added: >In the past I've had my signal handler return to random pieces of >code by not having the correct definition. Discussing whether or not such behaviour is a bug, Eddie Wyatt wrote: > It's questionable whether its a bug or not. The Sun man page reads: > > The handler routine can be declared: > > handler(sig, code, scp) > ... and then emphasized the impreciseness of the word ``can''. My addition to this conversation is as follows: Before ANSI C it was accepted that a function could be called with more arguments than it itself declared as formals. So for example you could have a call to "f(a,b)" where f() was defined beginning "int f(x) int x;", and `x' would get the value of the expression `a', `b' would be calculated and discarded, and Nothing Bad would happen. It was even somewhat accepted that you could do the reverse so long as f() itself didn't access its arguments; so, for example, with f() defined as follows: int f(a,b) int a,b; { if(a == 1) return(5); else return(b); } calls of f(1) would be legitimate. I would also like to point out that K&R says, on page 71, although admittedly not at all definitively: ``It is generally safe to deal with a variable number of arguments if the called function doesn't use an argument which was not actually supplied, and if the types are consistent.'' One further point: It may be argued that this doesn't apply to signal handlers, but I would say that conceptually there is a system function called when a signal happens, which in turn calls the user function. Therefore the user function is called using the C calling conventions no matter what happens at the system level when a signal happens. ajr -- "Comment, Spock?" "Very bad poetry, Captain."