Browse Source

[trac871] removed an assertion on arcount after inserting TSIG on further
thought with review comment. update the code comment accordingly.
in fact overflow could (probably) happen if the caller of toWire() tries to
render to many RRsets with an invalidly large buffer size limit. also,
the risk of overflow is not specific to this case; it can happen after
inserting ordinary RRs. So if we want to care about such cases we should
rather cover all of them than making a TSIG specifici check. For now,
I don't bother to check such stupid attempt of the caller. It would simply
result in bogus wire data and wouldn't make a program crash or something.

JINMEI Tatuya 14 years ago
parent
commit
28c50de2e9
1 changed files with 3 additions and 4 deletions
  1. 3 4
      src/lib/dns/message.cc

+ 3 - 4
src/lib/dns/message.cc

@@ -309,10 +309,9 @@ MessageImpl::toWire(AbstractMessageRenderer& renderer, TSIGContext* tsig_ctx) {
         tsig_ctx->sign(qid_, renderer.getData(),
                        renderer.getLength())->toWire(renderer);
 
-        // update the ARCOUNT for the TSIG RR
-        ++arcount;
-        assert(arcount != 0);   // this should never happen for a sane message
-        renderer.writeUint16At(arcount, header_pos);
+        // update the ARCOUNT for the TSIG RR.  Note that for a sane DNS
+        // message arcount should never overflow to 0.
+        renderer.writeUint16At(++arcount, header_pos);
     }
 }