Subject: Re: IPF in our source tree
To: None <tech-kern@netbsd.org>
From: Christos Zoulas <christos@astron.com>
List: tech-kern
Date: 06/02/2007 21:03:03
In article <20070602195100.GA341@NetBSD.org>,
Darren Reed  <darrenr@NetBSD.org> wrote:
>> >- Why was the use of caddr_t deprecated? I'm fine with void*,
>> >  I'd just like to know the technical reason for this...
>> 
>> Because caddr_t is a historical accident. It was meant to be void *, at a
>> time when void did not exist. Using void * instead of caddr_t eliminates
>> a large number of useless casts and helps lint with alignment warnings.
>> It should really be fixed upstream.
>
>Wholesale conversion of caddr_t -> void* doesn't work because some of
>the original caddr_t use involved pointer arithmetic and there is no
>such thing for void* (or so gcc 4 tells me.)

Yes, these should be type *, or char *, or uint8_t * depending on the context.

>
>> >- In some files under src/sys/dist/ipf/netinet the original code checks
>> >   the return value from BCOPYIN() but we have removed those checks. Why?
>> >   Any objections if I revert back to the original version?
>> 
>> The macros need to be made to work properly both from userland and kernel.
>
>THe BCOPYIN() macros are defined as:
>
>#  define       BCOPYIN(a,b,c)  (bcopy((a), (b), (c)), 0)
>#  define       BCOPYOUT(a,b,c) (bcopy((a), (b), (c)), 0)
>
>The usual use of this is:
>
>err = BCOPYIN(foo, bar, len);
>
>(Although there are some places that don't have "err =", those
> should be treated as bugs.)
>Is there some reason the above does not work on NetBSD?

That should work.

>> >- Some fuctions (e.g. fr_sttab_destroy) were converted from the old K&R(?)
>> >   style to the new ANSI(?) C style. Why? There are still functions using
>> >   the old style. Any objections if I revert back to the original version?
>> 
>> All the code should be converted to ansi upstream. Coordinate with Darren.
>
>The reason is that it makes the code able to be compiled wih the cc that
>shipped, out of the box, with SunOS4.

I thought that SunOS4 was dead. Anyway, you can just say that the last ipf
version that supports SunOS4 is x.y. And there are tools like protoize and
unprotoize for those who insist to upgrade.

christos