[tor-bugs] #8793 [Tor]: Resolve clang scan-build issues

[Tor Bug Tracker & Wiki]

#8793: Resolve clang scan-build issues
------------------------+-------------------------------------------------
     Reporter:  nickm   |      Owner:  nickm
         Type:  defect  |     Status:  needs_review
     Priority:  normal  |  Milestone:  Tor: 0.2.5.x-final
    Component:  Tor     |    Version:
   Resolution:          |   Keywords:  tor-client 024-backport 025-triaged
Actual Points:          |  Parent ID:
       Points:          |
------------------------+-------------------------------------------------

Comment (by nickm):

 > * 0fd0f5f7a9309fb90a6a4d8bad7d6399a45c7cc1 looks like a definite win
 >          - Could the bug it fixes ever arise under attacker control?

 That depends on whether the LD_BUG messages it's fixing can actually
 occur.  They're not in any released Tor yet, though: They affect code that
 was added for 9841, though, which hasn't been in any Tor release yet.

 >        * 4d51dcda2fa75a3841e041ab7c3de325d73e2850
 >          - But at least in theory we could have a hash table that large
 on a 64-bit
 >            platform
 >          - The numeric overflow would still be present because
 name##_PRIMES[]
 >            would still be an unsigned int.

 Yes, but we multiply that uint by a size_t , which does an integer
 promotion.  So it it won't overflow on 64-bit.

 >        * 9c9e07963dddff6e11330e9dc8ad7a6d37da4aa4
 >          - This patch looks okay but it overallocates slightly in the
 common
 >            case.  Maybe malloc(len*2+ellipses+1) rather than
 malloc(len*2+4) ?

 I'm okay wasting 3 bytes when reporting a tt_mem_op() failure in the
 tests.

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