[quagga-dev 1092] Re: point-to-point patch

Paul Jakma paul at clubi.ie
Wed Apr 28 17:07:40 BST 2004

On Wed, 28 Apr 2004, Andrew J. Schorr wrote:

> is an easy fix to that problem: in
> lib/zclient.c:zebra_interface_address_add_read(), instead of
> reading a flag byte, one can simply test the address after reading
> it in, and, if it's all zeroes, just replace it with a NULL
> pointer.  

Yes, that's what I assumed you were trying to do, not realising you
had added the flag byte.

> In fact, that's the way I coded it up the first time, but then I
> got nervous about whether INADDR_ANY could ever be a valid
> destination address. 

Nope. :)

> I may be wrong, but I do not believe that there is any existing code that
> checks for a zero (INADDR_ANY) destination address.  So if you guys would
> like to shift to that paradigm, it will actually be a larger patch.

Yep. Though, I suspect it's a thinko in the original code. The intent
was to dereference destination i suspect (though the test for NULL
would have to be on (struct connected *)->destination.s_addr, and 0
isnt NULL either.), hard to know for sure.

> Here's what the new patch would look like:

>    1. Whereever struct connected's are created, code will have to be added
>       to create an INADDR_ANY destination address if none was supplied.
>    2. Whereever the current code tests for a NULL destination address
>       (for example, zebra/interface.c:connected_dump_vty()), that will
>       have to be replaced by a test for INADDR_ANY or IN6ADDR_ANY, depending
>       on the prefix family.
>    3. Whereever the current code was using the destination address without
>       checking, it will have to be patched to test for INADDR_ANY or
>       IN6ADDR_ANY, depending on the context or prefix family.


> So that's why I think NULL pointers are the right way to go: I
> think it's a smaller patch that is more consistent with the
> existing behavior. But you guys are in charge, so I defer to your
> judgement.

Well, you're the one looking into the problem. My gut feeling though
is that always treating the destination as an address is more
intuitative (with IN?ADDR_ANY meaning 'no destination'), and having
the code treat it as such will aid the next person who comes along 
and tries to read the code.

Functionally, either way will work fine and NULL pointer as 'no
destination' will mean less churn, agreed.

Basically, what makes more sense to people? 'no destination' being 
IN?ADDR_ANY for the address or having destination be NULL? 

The only other thought I'd have on the subject is that if someone
were to try improve locality of struct connected (eg by moving the
prefixes into the struct itself), the IN?ADDR_ANY method would not
break. (apart from changing the method of reference to (struct
prefix)destination in struct connected in the code). (the concept of
'no destination' == IN?ADDR_ANY prefix remains valid).
> Regards,
> Andy

Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
	warning: do not ever send email to spam at dishone.st
A billion here, a billion there -- pretty soon it adds up to real money.
		-- Sen. Everett Dirksen, on the U.S. defense budget

More information about the Quagga-dev mailing list