Summary: | ASTERISK-10850: ast_random() has a small bug | ||
Reporter: | Simon Perreault (sperreault) | Labels: | |
Date Opened: | 2007-11-21 07:42:09.000-0600 | Date Closed: | 2007-11-21 12:17:01.000-0600 |
Priority: | Minor | Regression? | No |
Status: | Closed/Complete | Components: | Core/General |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | LONG_MIN has no positive equivalent. From POSIX's definition of labs(): "If the result cannot be represented, the behavior is undefined." The correct way to ensure a positive number without introducing any bias is to negate the bits themselves. ****** ADDITIONAL INFORMATION ****** Index: main/utils.c =================================================================== --- main/utils.c (revision 89464) +++ main/utils.c (working copy) @@ -1140,7 +1140,7 @@ if (dev_urandom_fd >= 0) { int read_res = read(dev_urandom_fd, &res, sizeof(res)); if (read_res > 0) - return labs(res); + return res < 0 ? ~res : res; } #endif #ifdef linux | ||
Comments: | By: Digium Subversion (svnbot) 2007-11-21 12:17:01.000-0600 Repository: asterisk Revision: 89487 U trunk/main/utils.c ------------------------------------------------------------------------ r89487 | mmichelson | 2007-11-21 12:17:00 -0600 (Wed, 21 Nov 2007) | 8 lines There existed about a 1 in 4 billion chance that reading from /dev/urandom would return LONG_MIN (1 in 9 quintillion if using 64-bit longs). Since there is no positive equivalent of LONG_MIN, the result of labs() in this case is unpredictable. This fixes that situation. (closes issue ASTERISK-10850, reported and patched by sperreault) ------------------------------------------------------------------------ |