[bind10-dev] Name::reverse()?

Evan Hunt each at isc.org
Fri Feb 19 17:25:42 UTC 2010


> - I'd use string::append instead of string::insert, and overall
>   simplify the loop logic
> - I'd build the reverse offset vector directly from the original
>   offsets using transform().  It should also help simplify the code
>   logic (by eliminating the boundary case consideration for
>   offsets_[0])

Fantastic.  I tried to figure out transform() and failed, so I came
up with this solution instead--if there's a smarter way, let's do that.

... I like your double-iterator approach.  However, wouldn't this work
equally well, without the transform()?

     // Copy the original name, label by label, from tail to head.
     vector<unsigned char>::const_reverse_iterator rit0 = offsets_.rbegin();
     vector<unsigned char>::const_reverse_iterator rit1 = rit0 + 1;
     string::const_iterator n0 = ndata_.begin();
     while (rit1 != offsets_.rend()) {
         retname.ndata_.append(n0 + *rit1, n0 + *rit0);
+        retname.offsets_.push_back(retname.ndata_.size());
         ++rit0;
         ++rit1;
     }
     retname.ndata_.push_back(0);

> Currently, (AFAICS) the only usage of this method is the following
> line of data_source_sqlite3.cc:
> 
>     const char *c_rname = qname.reverse().toText().c_str();
> 
> This seems to me a very special case.

This won't be the only use of this function, it's just the first.

For one thing, since the SQL schema for zone records includes a reversed
name, we'll need to be able to create those names when inserting into the
SQL data source.  Right now I'm doing that in python (which includes a
generic reverse() function) but DDNS and probably *XFR will require C++ to
be able to do the same thing.

Also, since the database is indexed by the reversed-name field, I expect
there would probably a small speedup for large zones if we reversed the
name before doing the database query.  That's a minor point at this stage
of development, though.

For those things, during the prototype phase, there are other ways to
proceed.  But I need findPreviousName() for NSEC support; therefore
a reverse() function has now become essential.

As to whether it belongs in the Name class... I could code one using the
existing Name API; it's easy enough to do with split() and concatenate().
But that requires multiple copies and transformations per label.  A
dedicated reverse() function that acts directly on the underlying
Name data is a single copy.

So I believe it does belong in the Name class, or at least in a derived
class that has full access to the Name data.  And I don't really see any
advantage to having a class ReversibleName, as opposed to one extra method
in Name.

                                        eh




More information about the bind10-dev mailing list