struct fr_connection 'number' label
Looking through the code here: https://github.com/FreeRADIUS/freeradius-server/blob/master/src/main/connect... Should fr_connection->number match fr_connection_pool_t->count … it seems as though number is being assigned the incremented value of count and number is a signed int whereas count is an unsigned int? What happens if count grows larger than the max signed int? Should both of these be changed to a long or unsigned long to reduce the chance of overflow to a near impossibility? -- Aaron
On 26 Jun 2013, at 16:12, Aaron Hurt <ahurt@ena.com> wrote:
Looking through the code here:
https://github.com/FreeRADIUS/freeradius-server/blob/master/src/main/connect...
Should fr_connection->number match fr_connection_pool_t->count … it seems as though number is being assigned the incremented value of count and number is a signed int whereas count is an unsigned int? What happens if count grows larger than the max signed int? Should both of these be changed to a long or unsigned long to reduce the chance of overflow to a near impossibility?
Arguably, yes. Though it is unlikely that the counters would ever get that high, and there would be no side effects other than a negative integer being displayed. So yes, may as well make them uint64_t. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team
Aaron Hurt wrote:
Should fr_connection->number match fr_connection_pool_t->count … it seems as though number is being assigned the incremented value of count and number is a signed int whereas count is an unsigned int? What happens if count grows larger than the max signed int? Should both of these be changed to a long or unsigned long to reduce the chance of overflow to a near impossibility?
If it opens 100 new connections a second, it will take a month to roll over 2^32. Annoying, but not critical. Making it a uint64_t would fix that for all reasonable definitions of "forever". Alan DeKok.
Thank you all, I see the commit. Much appreciated. -- Aaron On Jun 26, 2013, at 10:24 AM, Alan DeKok <aland@deployingradius.com> wrote:
Aaron Hurt wrote:
Should fr_connection->number match fr_connection_pool_t->count … it seems as though number is being assigned the incremented value of count and number is a signed int whereas count is an unsigned int? What happens if count grows larger than the max signed int? Should both of these be changed to a long or unsigned long to reduce the chance of overflow to a near impossibility?
If it opens 100 new connections a second, it will take a month to roll over 2^32.
Annoying, but not critical. Making it a uint64_t would fix that for all reasonable definitions of "forever".
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html
participants (3)
-
Aaron Hurt -
Alan DeKok -
Arran Cudbard-Bell