[tor-bugs] #1789 [Tor Relay]: Wake-up from Hibernation Occurs Day 1 Each Month

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Tue Sep 21 18:40:58 UTC 2010


#1789: Wake-up from Hibernation Occurs Day 1 Each Month
---------------------------------+------------------------------------------
 Reporter:  BarkerJr             |         Type:  defect   
   Status:  closed               |     Priority:  minor    
Milestone:  Tor: 0.2.2.x-final   |    Component:  Tor Relay
  Version:  Tor: 0.2.2.14-alpha  |   Resolution:  fixed    
 Keywords:                       |       Parent:           
---------------------------------+------------------------------------------
Changes (by nickm):

  * status:  needs_review => closed
  * resolution:  => fixed


Comment:

 Replying to [comment:24 arma]:

 > I'm not certain of my C anymore, but it seems like the "acct_max >
 SOFT_LIM_BYTES" part here is redundant, yes? If acct_max - SOFT_LIM_BYTES
 is negative, it's hardly going to find itself > soft_limit, which is a
 uint64, right?

 acct_max is unsigned, so acct_max - SOFT_LIM_BYTES can't be negative.  If
 you take a uint64_t and subtract a number from it, the result is a
 uint64_t, even if it wraps around.

 To check how C works, write a test program:
 {{{
 #include <stdio.h>
 int main(int argc, char **argv)
 {
   unsigned a;
   a = 99;
   printf("a - 100 = %u\n", a-100);
   printf("(a - 100 > 1) == %d\n", (a-100)>1);
   return 0;
 }
 }}}

 > I mean, I can see the underflow worry if you were assigning acct_max -
 SOFT_LIM_BYTES to a uint64_t before the comparison. But you're not. Are
 compilers really so stupid? Or to say it more nicely, are compilers really
 so fickle?

 Neither.  This is how unsigned arithmetic works in C.  When you take a
 signed integer and an unsigned integer and do a binary operation with
 them, the signed int is first converted to an unsigned[*] before the
 operation happens.  Unsigned overflow/underflow is defined to wrap around.



 Fixed the other stuff, and merging.

 [*] Unless the signed type is larger than the unsigned type, such that it
 can hold every legal value of the unsigned type.  (K&R 2nd ed Section A6)

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1789#comment:30>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list