lkml.org 
[lkml]   [1996]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: On SIGCHLD signal semantics
   Date: Sat, 22 Jun 1996 10:17:51 -0400
From: Mark Swanson <mark@bugless.com>

As an aside, Linux appears to be non POSIX-compliant when it deals with
sigaction signal handlers. In the struct sigaction, the sa_handler member
is defined as void(*)(int) on Linux and in my POSIX book void(*)(). Also,
FreeBSD uses the POSIX semantics as well. Is my POSIX book outdated or is
Linux non-POSIX compliant? (I'm betting on Linux being correct, but
two other sources are contradictory...)

You're right; Linux is doing the wrong thing w.r.t. POSIX here. POSIX
requires that a signal function handler take at least one argument,
which is "int signo", and a strictly-complaint POSIX application should
declare signal handling functions as either "int sighandler()" or
"int sighandler(int signo)".

However, many POSIX-complaint OS's may extend the number of arguments
passed by the OS to the signal handler.

POSIX does require that the function pointer in sigaction be declared as
void (*)(), though. The Rationale section of the standard indicated
that at one point there was a proposal that the function pointer be
declared as void (*)(int sig, ...). However, this would force all
signal handlers to be declared with the variable arguments notation,
thus breaking existing programs. This was deemed as bad, so it's left
as void (*)(). Note that since this is C, not C++, void (*)() means
that nothing is said about the number of arguments. (In C++, void(*)()
is the same as ANSI C's void(*)(void).)

- Ted



\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.012 / U:0.620 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site