Have you considered keeping just the 3-argument sig-handlers and writing a one-argument stub handler for each that merely calls the 3-argument one (with a NULL 2nd arg).
Although it looked to be an elegant solution at first, I now realize that it might create some complications on systems where 'sigaction' is present but 'SA_SIGINFO' is not (like Hurd); or where 'sigaction' itself is missing. Due to the following block and a similar one in init_ui, the 'struct sigaction' variables are only instantiated and assigned when SA_SIGINFO is present in signal.h. #ifdef SA_SIGINFO static struct sigaction sig_segv; static struct sigaction sig_int; static struct sigaction sig_fpe; static struct sigaction sig_ill; #endif /* SA_SIGINFO */ Since the mere presence of 'sigaction' does not offset the absence of 'SA_SIGINFO' and we are stuck with one parameter handlers, the latter is used as the defining entity. Moreover we do not have to separately consider cases where 'sigaction' itself is absent. If there is no 'sigaction', then there is no 'SA_SIGINFO' as well. When the one-argument stub calls the three-argument handler, we would basically check whether the second parameter is NULL and act accordingly. To avoid a compile time error on Hurd-like kernels we would need to insert #ifdef...#else...#endif blocks in the three-argument handler so that the mention of 'sigaction' and 'struct sigaction' variables do not throw an error. The argument that the #ifdef...#endif block be removed and 'struct sigaction' variables be declared in all cases, so that insertion of #ifdef...#else...#endif blocks are not necessary in the three-argument handler is flawed because this will not take into consideration cases where 'sigaction' itself is absent.
That would avoid a lot of the duplication.
I feel this duplication is a price we can pay for a clearer code. Having the control flow from a stub handler to the other; the checking of the second parameter; the insertion of #ifdef...#else...#endif in the three parameter handlers will reduce the readability. In any case the duplication is very less, and having a separate handler for the two cases keeps things a tad simpler. Note: please find a 'git diff' attached. Though it compiles and works on Linux kernel based systems, it is not complete. It will compile on Hurd but not on 'sigaction' less systems. I thought it will make it clear what I am trying to convey. Maybe I am taking a wrong aproach... Happy hacking, Debarshi -- GPG key ID: 63D4A5A7 Key server: pgp.mit.edu
ui.c.git-diff1
Description: Binary data
_______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
