Re: [tor-bugs] #13635 [Tor]: Time to retire SIZE_T_CEILING?

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#13635: Time to retire SIZE_T_CEILING?
-------------------------+--------------------------------
     Reporter:  nickm    |      Owner:
         Type:  defect   |     Status:  closed
     Priority:  normal   |  Milestone:  Tor: 0.2.6.x-final
    Component:  Tor      |    Version:
   Resolution:  wontfix  |   Keywords:
Actual Points:           |  Parent ID:
       Points:           |
-------------------------+--------------------------------
Changes (by yawning):

 * status:  new => closed
 * resolution:   => wontfix


Comment:

 Replying to [comment:2 cypherpunks]:
 > > On the other hand, if malloc _would_ give you that much memory, then
 who are we to argue with it?
 >
 > What part of code will to request and will to fill so much of memory at
 once? It's bug if code tries to decode stuff or to read so much bytes from
 file at once. Those asserts never shoots to sane code.

 I agree with this assessment.  If we ever end up malloc()ing gigantic
 amounts of memory we can revisit this, but I don't see that happening in
 the near future.

 For what it's worth the default Linux overcommit behavior
 (`vm.overcommit_memory=0`) would return NULL for the kinds of errors this
 is intended to catch anyway, but having the assert is better for debugging
 (and covers system that always allow overcommit for some reason).

 Closing per discussion with nickm on irc.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/13635#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs