On Wednesday 2008-04-09 15:12, Patrick McHardy wrote:
>> > > +enum {
>> > > + __NFPROTO_MIN = AF_MAX,
>> > > + NFPROTO_ARP,
>> > > + __NFPROTO_MAX,
>> > > +};
>> > > [...]
>> > > - xt = kmalloc(sizeof(struct xt_af) * NPROTO, GFP_KERNEL);
>> > > + xt = kmalloc(sizeof(struct xt_af) * __NFPROTO_MAX, GFP_KERNEL);
>> > Thats quite ugly. I'd also prefer to keep the size in
>> > the nf_hooks declaration and elsewhere.
>> >
>> > How about:
>> >
>> > enum {
>> > __NFPROTO_MIN = AF_MAX - 1, (AF_MAX is actually max + 1)
>> > NFPROTO_ARP,
>> > __NFPROTO_MAX
>> > };
>> > #define NFPROTO_MAX (__NFPROTO_MAX - 1)
>>
>> Then what's the point of defining __NFPROTO_MAX?
>
> Its so ugly that everyone adding new values will notice it
> and not add something after it :)
>
>> > The array declarations should then use NFPROTO_MAX + 1.
>>
>> Why +1 if MAX is ARP?
>
> Because array indices start at zero.
>
It's all whacked up, srsly.
#define AF_RXRPC 33
#define AF_MAX 34
IMHO we should just:
enum {
NFPROTO_FOO = AF_MAX,
NFPROTO_BAR,
NFPROTO_BAZ,
NFPROTO_MAX,
};
and use NFPROTO_MAX in lieu of AF_MAX where due.
Putting that into place with ARP means:
enum {
NFPROTO_ARP = AF_MAX,
NFPROTO_MAX,
};
and use NFPROTO_MAX. No __NFPROTO_MIN, no __NFPROTO_MAX, and
less confusion overall. How about it? :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
