[asterisk-dev] [Code Review] 4542: DNS: Add NAPTR support and tests

[Mark Michelson]

> On March 31, 2015, 3:25 p.m., Matt Jordan wrote:
> > /team/group/dns/main/dns_naptr.c, lines 420-421
> > <https://reviewboard.asterisk.org/r/4542/diff/2/?file=73012#file73012line420>
> >
> >     The asserts here are appropriate.
> >     
> >     However, if there is an error in the record, such that the memcmp never returns true, we'll get stuck in this loop.
> >     
> >     It may be good to have a 'fail safe' break out in the loop, after the asserts. That way in dev-mode we'll catch issues, but in production systems, the allocation of the NAPTR record will fail and we can (hopefully) gracefully handle it.

I'm not sure I agree with this.

The reason why these are assertions instead of if statements is because the record we have been given came from the DNS answer in the first place, so it HAS to be present in the answer. Even if the answer is malformed in some way, the record we've been given comes from that answer, so it needs to be present.

On the other hand, it's not difficult to add a fail-safe if check here just to be certain.


> On March 31, 2015, 3:25 p.m., Matt Jordan wrote:
> > /team/group/dns/main/dns_naptr.c, lines 447-449
> > <https://reviewboard.asterisk.org/r/4542/diff/2/?file=73012#file73012line447>
> >
> >     Suggestion: since this is repeated after each check, you may want to macro-tize it:
> >     
> >     #define CHECK_END_OF_RECORD do { \
> >         if (ptr => end_of_record) { \
> >             return NULL; \
> >         } } while (0)
> >     
> >     
> >     Then you can just put:
> >     
> >     ptr += 2;
> >     CHECK_END_OF_RECORD;
> >     
> >     Or something like that.
> 
> rmudgett wrote:
>     Doing this hides return points.  Which adds a potential for memory and ref leaks.
> 
> Matt Jordan wrote:
>     True, right now all of these do not perform cleanup. In fact, the entire exercise here is mostly to figure out how long everything is so that things can be allocated.
>     
>     This is a long routine; sometimes it's nice to take repetitive code and squish it down. If Mark feels like that injects too much risk, I have no problem with the finding being dropped.
>

Yeah, I'm not proud of this routine's length, and I wanted to break it up more than it already is, but unfortunately everything I came up with ended up either being uglier or questionable.

The macro idea has some merit to it because it prevents fat-fingering and accidentally comparing the wrong values or typing a > instead of a >=. But as Richard pointed out, this hides return points, which in my opinion ultimately made the code less readable.

I could make a compromise and have

#define CHECK_END_OF_RECORD (ptr >= end_of_record)
...
if (CHECK_END_OF_RECORD) {
    return NULL
}

Readability is a bit compromised, but the typo possibilities are eliminated. I'll just go with that.


- Mark


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4542/#review14972
-----------------------------------------------------------


On March 27, 2015, 2:45 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4542/
> -----------------------------------------------------------
> 
> (Updated March 27, 2015, 2:45 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> -------
> 
> This adds NAPTR support for DNS in Asterisk.
> 
> The main parts of this are the functions for allocating a DNS NAPTR record when a resolver wishes to add a NAPTR record, the sorting algorithm for sorting DNS NAPTR records, and the tests that use a mock DNS resolver.
> 
> NOTE: There is likely to be some overlap here in this review and Josh's SRV review (/r/4528). Our stance on this is that we will factor out the duplicated code once both SRV and NAPTR have been merged into the main DNS branch. The factoring out of common functions will be placed in its own review.
> 
> 
> Diffs
> -----
> 
>   /team/group/dns/tests/test_dns_naptr.c PRE-CREATION 
>   /team/group/dns/res/res_resolver_unbound.c 433573 
>   /team/group/dns/main/dns_naptr.c 433573 
>   /team/group/dns/main/dns_core.c 433573 
>   /team/group/dns/include/asterisk/dns_internal.h 433573 
> 
> Diff: https://reviewboard.asterisk.org/r/4542/diff/
> 
> 
> Testing
> -------
> 
> All previous DNS tests continue to pass, and all new tests added in this review pass as well.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150401/75d4fd01/attachment-0001.html>