[parted-devel] porting to FreeBSD

Debarshi 'Rishi' Ray debarshi.ray at gmail.com
Thu Mar 1 12:23:56 CET 2007


Jim wrote:
>> Whoa.  FreeBSD provides sigaction.
>> Why do you want to skip the test for it on that system?

Siavosh wrote:
>>> -AC_CHECK_FUNCS(sigaction)
>>> +if test "$OS" != freebsd; then
>>> +   AC_CHECK_FUNCS(sigaction)
>>> +fi
>>>  AC_CHECK_FUNCS(getuid)

Siavosh wrote:
> Well FreeBSD does provide sigaction but it misses (except for the
> CURRENT (unstable) branch) many MACRO constants that you can check the
> value of siginfo_t variables against. But I think that change in the
> configure.ac is avoidable.

GNU systems running Hurd also do not possess certain macro constants which are
used by sigaction. Please read on...

Jim wrote:
>> The following change looks avoidable.
>> There should be a move to *remove* casts, not to add them,
>> especially, ones that look like that :)
>> I'll bet we can find a better way.

Saivosh wrote:
>>> -    signal (SIGFPE, &sigfpe_handler);
>>> +    signal (SIGFPE, (void (*) (int)) &sigfpe_handler);

Siavosh wrote:
> I agree that there should be a move to remove the casts but only by
> making the argument of correct type. Here we are using one
> sigfpe_handler function for two cases:
> 1. The system has sigaction which takes a pointer to a function with
> three arguments.
> 2. The system has signal which takes a pointer to a function with one 
> arguments.

One encounters the same problem with Hurd kernel. Although 'sigaction' is
available in 'signal.h', the absence of SA_SIGINFO does not allow the use of
a three parameter signal handler with 'sigaction'. One is stuck with the
single parameter 'signal'-style signal handler. So what I did was write a
separate signal handler for the two cases, having the same name but with
different parameter lists. This is not difficult, since all that the three
parameter signal handler was doing, over and above the single parameter one,
was to provide some detail about the signal that was being handled. The loss
of this verbosity, when one can not use a three parameter list signal handler
with 'sigaction' is acceptable in my opinon.

I had sent a patch to make Parted compile on GNU (Hurd based) systems, which
does just this. I used a #ifdef SA_SIGINFO...#else...#endif structure to
selectively handle the two cases. I am still waiting for everybody's opinion
regarding this, but atleast roughly this is what we can do in my opinion.

Siavosh wrote:
> Now in any architecture that I know of functions with up to three
> integer or pointer arguments pass their arguments in the registers so
> this works. But according to a C compiler this generates a warning or
> error depending on the situation.

A warning is as bad as an error in this case, since we are using the -Wall
flag during compilation, and all warnings are flagged as errors.

Happy hacking,
Debarshi
-- 
husband    v. use sparingly; conserve; save
husbandry  n. frugality; thrift; agriculture
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/parted-devel/attachments/20070301/29650b32/attachment.pgp


More information about the parted-devel mailing list