> a. Used #ifndef..#endif on HAVE_SIGACTION and SA_SIGINFO to
> selectively define those structure and functions which will go missing
> when 'sigaction' and/or 'SA_SIGINFO' are absent. I have nested the two
> cases to make them more granular.
Ack. I just didn't catch why you nested both? Wouldn't the SA_SIGINFO
be enough?
There are systems which will have neither have 'sigaction' nor
'SA_SIGINFO', while there will be some which will have 'sigaction' but
not 'SA_SIGINFO' (like Hurd based ones). Just enclosing everything
based on 'SA_SIGINFO' would (and was) giving build errors in Hurd.
I could have kept them sequential instead of nesting, but nesting
implies that if there is no 'sigaction' then 'SA_SIGINFO' has to be
missing, and not vice versa. I can not imagine a case where we will
have 'SA_SIGINFO' and 'sigaction' will be absent.
> c. I have not used
> #define sigaction (a, b, c)
> Instead used a blank function definition, and a couple of blank
> structures to keep things readable.
I just wonder if it's the most common why of doing that kind of
thing. I think would be good to use the most common way when
possible. I don't know if it'll looks cleaner or more confuse for
someone looking at the code by the first time.
struct siginfo_t {
int si_code;
};
This was necessary since info->si_code is referenced in the three
parameter handlers. Defining it as void would give a error while
trying to dereference the member 'si_code'.
int sigaction (int signum, const struct* sigaction, struct* sigaction)
{
}
This makes it very clear what 'sigaction' is supposed to be. After all
isn't it advised to avoid using the preprocessor if the language
proper can handle it?
I will wait for Jim's comments too.
Happy hacking,
Debarshi
--
GPG key ID: 63D4A5A7
Key server: pgp.mit.edu
_______________________________________________
parted-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/parted-devel
