"Debarshi 'Rishi' Ray" <[EMAIL PROTECTED]> wrote: >> 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.
It's easy to handle the absence of sigaction. Add this at the top: #ifndef HAVE_SIGACTION # define sigaction(a,b,c) /* empty */ #endif > 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. No! Duplication makes maintenance harder. It becomes too easy to change one copy but not the others. > 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. Shouldn't need any new #ifdefs. Thanks for persevering. _______________________________________________ parted-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/parted-devel
