[tor-commits] [tor/release-0.2.4] Revert e443beff and solve it a different way

[arma at torproject.org]

commit f51add6dbcef073d3ba57df13eee3c99d647fde9
Author: Roger Dingledine <arma at torproject.org>
Date:   Thu Sep 5 01:41:07 2013 -0400

    Revert e443beff and solve it a different way
    
    Now we explicitly check for overflow.
    
    This approach seemed smarter than a cascade of "change int to unsigned
    int and hope nothing breaks right before the release".
    
    Nick, feel free to fix in a better way, maybe in master.
---
 src/or/onion.c |    5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/or/onion.c b/src/or/onion.c
index 8e3e487..1a0bcf1 100644
--- a/src/or/onion.c
+++ b/src/or/onion.c
@@ -212,7 +212,7 @@ static uint16_t
 decide_next_handshake_type(void)
 {
   /* The number of times we've chosen ntor lately when both were available. */
-  static unsigned int recently_chosen_ntors = 0;
+  static int recently_chosen_ntors = 0;
 
   if (!ol_entries[ONION_HANDSHAKE_TYPE_NTOR])
     return ONION_HANDSHAKE_TYPE_TAP; /* no ntors? try tap */
@@ -227,7 +227,8 @@ decide_next_handshake_type(void)
      * got here first. In any case this edge case will only become relevant
      * once tap is rare. We should reevaluate whether we like this decision
      * once tap gets more rare. */
-    if (ol_entries[ONION_HANDSHAKE_TYPE_NTOR])
+    if (ol_entries[ONION_HANDSHAKE_TYPE_NTOR] &&
+        recently_chosen_ntors <= num_ntors_per_tap())
       ++recently_chosen_ntors;
 
     return ONION_HANDSHAKE_TYPE_NTOR; /* no taps? try ntor */