[parted-devel] Parted on GNU Hurd based systems

[Debarshi 'Rishi' Ray]

> > 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