[quagga-dev 5274] Re: mes_lookup / LOOKUP robustness

Andrew J. Schorr aschorr at telemetry-investments.com
Wed Feb 27 01:43:24 GMT 2008

On Tue, Feb 26, 2008 at 05:31:05PM -0500, James Carlson wrote:
> I'm somewhat unconvinced, though, that mes_lookup ought to return
> anything as grotty as "(nil)".  Either the set of messages is large
> and dependent on something not in the design of the code itself (e.g.,
> LOOKUP(attr_str, type) in bgp_attr.c), so some sort of
> legible-to-humans "not found in list" entry needs to be possible, or
> the set is constrained by the design (most of the ospfd usages) and
> anything outside the range should intentionally drop core, because
> it's a bug.
> I don't think "(nil)" really satisfies either situation, and it looks
> at least a bit ugly to me to use the same common function for two very
> different cases.

I concur -- if the message list is not properly accessed, then it's a bug,
and I should think a core dump might be the best bet.  In fact, this is
why I originally used zlog_warn to complain about the message being
in the wrong position (but then Paul convinced me that there are certain
cases where it's fine for the message list not to be in sequence, so
we downgraded it to a debug message).  If the function is called with
1 or more invalid arguments, perhaps we should just call abort()?

Or how about a compromise position -- the existing function could call
abort() if it detects any irregularity in the arguments, and we could
add a new more forgiving function that returns "(nil)" for unknown
messages.  It seems to me that forcing a conscious choice would help
to clarify the programmer's expectations and see that they are enforced
at runtime...


More information about the Quagga-dev mailing list