• Suppose you declare a pointer which points to an integer value, like int *ptr, now this pointer doesn’t have a valid address. We can use the address of another variable and assign this address to our pointer like

• Another way is dynamic memory allocation. In this technique pointer is assigned a valid address at run time from the heap segment. This is the best way to assign addresses to pointers as it gives us the flexibility of deciding the amount of memory we want our pointer to access and the type of data we will store in the block of memory. Dynamic allocation of memory is done using malloc(), calloc(),and realloc() system calls.
  For e.g. lets assign an address to ptr
                       ptr = (int*)malloc(sizeof(int) * 10);

• This last method is specific to character arrays
  for e.g. char *ptr = “Hello world”
  ‘ptr’ is a pointer which would store the address at which a character is to be stored. In our e.g. ptr would hold the address at which ‘H’ is stored using this address we access the entire string.

• ptr is the identifier we can straight away conclude that ptr is an array (on moving right) of (on moving left) pointers, after square brackets the innermost braces close. So we’re at *ptr[]
• Next on moving right ptr is an array of pointers to a (on moving right) function (then moving left) that returns a pointer. At this point we’re at (int*(*ptr[])() )
• Finally the outermost braces give us : ptr is an array of pointers to a function returning pointer to (on moving right) an array of integer pointers(on moving left).

• Using our convention we start from ptr, now moving right we see that ptr is a function , then we reach the end of the innermost brace but we still don’t know what this function returns to find out we move to the left of ptr and find ‘*’ operator so we conclude that ptr is a function that returns a pointer. At the end of this we’re at: *ptr() (ptr is a function returning a pointer), but we don’t know what the returning pointer points to.
• Going out of the inner most braces on the right we see square brackets so that means the pointer returned by ptr would point to an array, now on moving left we find what this array stores. It stores pointers. So at this stage we have : *(*ptr())[] (ptr is a function returning a pointer to an array of pointers). Remember we don’t know the pointers in the array point to.
• Now to the outermost braces on moving right its clear that the pointers in the array each point to a function and on moving left we find the return type of these functions is a char type variable.

1. *(*(*arr[3]))[3]
2. *(*arr[5])( ))
3. char(*ptr)( )

1. ‘arr’ is an array ( of size 3 ) of pointers each of which points to a pointer that points to an array ( of size 3 ) of pointers.( Remember if you encounter nothing on the right simply move to the left)
2. ‘arr’ is an array ( of size 5 ) of pointers each of which points to a function that returns a pointer.
3. ‘ptr’ is pointer to a function that returns a char type variable.

There are a total of 64 signals defined in Linux. These have been divided into various sections :

1. Program error signals
2. Termination signals
3. Alarm signals
4. Asynchronous I/O signals
5. Job control signals
6. Operation error signals
7. Miscellaneous signals

All these are defined in header file signal.h.

When generated these signals would execute there default behavior. But we can change this by redefining what the signal should do when its generated. This new definition is called a handler.

NOTE : SIGKILL and SIGSTOP can’t be caught or handled.

The signal system call – int signal(int signum, sighandler_t handler) is used to register a signal handler which would be invoked when the signum signal is generated.

Using signal() system call has some major drawbacks, of which the most significant is that its behavior varies across different versions of UNIX and Linux. Others include:

• Undefined behavior if the signal handler is already running because signals are not blocked while the current handler is executing.
• We can’t pass arguments to the handler.
• No information about the origins of the signal.
• The signal function generally resets back to its default behavior, which is more often then not termination of the current process. Now, suppose a signal is generated and between the time the signal is generated and the handler  re-installs its definition, another instance of the signal occurs. In this case the default behavior which is generally termination of process, would happen.

So, I think its safe to say that signal() is a fairly primitive and unsafe way to handle incoming signals.

Contrary to signal(), sigaction() provides a vast variety of options while handling signals but, with added complexity.

This is the prototype for sigaction() system call – int sigaction(int signum, const struct sigaction *act, struct sigaction *oldact)

The 1st argument takes the signal which is to be handled, the 3rd argument is used to define the previous behavior of the signal. The 2nd argument is a pointer to sigaction which is a kernel data structure its defined as:

struct sigaction {
void     (*sa_handler)(int);
void     (*sa_sigaction)(int, siginfo_t *, void *);
sigset_t   sa_mask;
int        sa_flags;
void     (*sa_restorer)(void);
};
– sa_handler specifies the action to be associated with signum. This function receives  the  signal no. as its only argument.

– Parameters in sa_sigaction i.e void* is used to send arguments to the handler and siginfo_t is a structure which gives information about the whereabouts of the signal and other critical information. Its defined as:

siginfo_t {
int      si_signo;    /* Signal number */
int      si_errno;    /* An errno value */
int      si_code;     /* Signal code */
int      si_trapno;   /* Trap number that caused
hardware-generated signal
(unused on most architectures) */
pid_t    si_pid;      /* Sending process ID */
uid_t    si_uid;      /* Real user ID of sending process */
int      si_status;   /* Exit value or signal */
clock_t  si_utime;    /* User time consumed */
clock_t  si_stime;    /* System time consumed */
sigval_t si_value;    /* Signal value */
int      si_int;      /* POSIX.1b signal */
void    *si_ptr;      /* POSIX.1b signal */
int      si_overrun;  /* Timer overrun count; POSIX.1b timers */
int      si_timerid;  /* Timer ID; POSIX.1b timers */
void    *si_addr;     /* Memory location which caused fault */
long     si_band;     /* Band event (was int in
glibc 2.3.2 and earlier) */
int      si_fd;       /* File descriptor */
short    si_addr_lsb; /* Least significant bit of address
(since kernel 2.6.32) */
}

– sigset_t sa_mask is a set of signals to be blocked during execution of the signal handler.   This is called signal masking. The blocked signals are sent to the sigpending queue, sigpending is a kernel structure defined in signal.h which is used to queue all the signals raised in the kernel space and are blocked in the user space.

– sa_flags specify a set of flags which modify the behavior of the signal. For e.g. if SA_SIGINFO then sa_sigaction specifies the signal handling function for signum not sa_handler. This is used when we want to define our own handler. List of all the flags is :

• SA_NOCLDSTOP
• SA_NOCLDWAIT
• SA_NODEFER
• SA_ONSTACK
• SA_RESETHAND
• SA_RESTART
• SA_SIGINFO

– sa_restorer should not be by the user, its used internally by the Linux kernel while handling a pending unblocked signal.

Its quiet obvious that sigaction() allows more precise and safe handling of signals along with portability and takes care of the anomalies or loop holes created while using signal() system call.