# libc and random functions - Thread: https://externals.io/message/31057 - Original archive: https://news-web.php.net/php.internals/31057 - Started by Keryx Web on 2007-07-18T18:20:42+00:00 - Messages: 11 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #31057 — Keryx Web — 2007-07-18T18:20:42+00:00 URL: https://externals.io/message/31057#31057 I do not know if this post made it to the list a while ago. No one answered and i see I used the wrong account to send it. Please forgive me if this is a redundant re-post. This is a suggestion I think would not be too hard to implement: Skip libc for all random functions. As I see it there is no reason to keep it. I can't think of any application that would break if `rand()` would produce better random results at a higher speed. So basically what I am saying is this: Implement the mersenne twister in the back of all random functions. 1. Make `rand()` an alias to `mt_rand()` 2. Make `srand()` an alias to `mt_srand()` (And since they are redundant give an E_STRICT?) 3. Make `getrandmax()` an alias to `mt_getrandmax()` 4. Have `array_rand()` implement MT in the back (if it is not doing so already) Lars Gunther P.S. For an introduction to who I am one might read: http://www.webstandards.org/action/edutf/interviews/gunther-en/ and look at http://www.flickr.com/photos/keryxgunther/143376264/ --- ## #31058 — Ilia Alshanetsky — 2007-07-18T18:23:38+00:00 URL: https://externals.io/message/31057#31058 · In reply to: #31057 Do you have a patch? > I do not know if this post made it to the list a while ago. No one > answered and i see I used the wrong account to send it. Please > forgive me if this is a redundant re-post. > > > This is a suggestion I think would not be too hard to implement: > > Skip libc for all random functions. As I see it there is no reason > to keep it. I can't think of any application that would break if > `rand()` would produce better random results at a higher speed. > > So basically what I am saying is this: Implement the mersenne > twister in the back of all random functions. > > 1. Make `rand()` an alias to `mt_rand()` > 2. Make `srand()` an alias to `mt_srand()` (And since they are > redundant give an E_STRICT?) > 3. Make `getrandmax()` an alias to `mt_getrandmax()` > 4. Have `array_rand()` implement MT in the back (if it is not doing > so already) > > > > Lars Gunther > > P.S. For an introduction to who I am one might read: > http://www.webstandards.org/action/edutf/interviews/gunther-en/ > and look at > http://www.flickr.com/photos/keryxgunther/143376264/ > > -- > > > Ilia Alshanetsky --- ## #31101 — Keryx Web — 2007-07-19T13:41:29+00:00 URL: https://externals.io/message/31057#31101 · In reply to: #31058 Ilia Alshanetsky wrote: > Do you have a patch? Also @Antony Dovgal in the "let blocks" thread Short answer: No. The reason I posted my suggestions on this list was that a while ago I had a few ideas as to how PHP could be improved. A seasoned PHP developer suggested that I'd take my suggestions to this list. As I have no "commit karma" - as it has been dubbed elsewhere - I have tried to be polite and keep a low profile, only speaking out when I thought that my perspective could be of value to the discussion at hand. Now I have two questions: (1) Is it considered bad form to make feature suggestions on this list, even though I am not in the position to make any patches myself? (2) If so, can anyone point me to the place where such a feature request might be made? And now - hypothetically speaking - maybe I could find some time during this autumn to actually learn a bit more C and make a patch. Wouldn't it be better if I made a patch that the community thought worthwhile and not spend my time developing something none ever would commit? Just having someone say: "That sounds like a good idea", would be an encouragement for such an undertaking. Lars Gunther --- ## #31102 — David Coallier — 2007-07-19T13:47:56+00:00 URL: https://externals.io/message/31057#31102 · In reply to: #31101 > Ilia Alshanetsky wrote: > > […] > > Also @Antony Dovgal in the "let blocks" thread > > Short answer: No. > > The reason I posted my suggestions on this list was that a while ago I > had a few ideas as to how PHP could be improved. A seasoned PHP > developer suggested that I'd take my suggestions to this list. > > As I have no "commit karma" - as it has been dubbed elsewhere - I have > tried to be polite and keep a low profile, only speaking out when I > thought that my perspective could be of value to the discussion at hand. > > Now I have two questions: > > (1) Is it considered bad form to make feature suggestions on this list, > even though I am not in the position to make any patches myself? > > (2) If so, can anyone point me to the place where such a feature request > might be made? > > And now - hypothetically speaking - maybe I could find some time during > this autumn to actually learn a bit more C and make a patch. Wouldn't it > be better if I made a patch that the community thought worthwhile and > not spend my time developing something none ever would commit? > > Just having someone say: "That sounds like a good idea", would be an > encouragement for such an undertaking. > > > Lars Gunther > > -- > > > > Side note for you Lars, I have a patch for the initial request on this thread about rand -> mt_rand, etc. I'm just making sure i'm not breaking any extensions, and then I'll send it on the list :) Should be in about an hour or so. -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #31103 — Antony Dovgal — 2007-07-19T14:02:09+00:00 URL: https://externals.io/message/31057#31103 · In reply to: #31101 > Ilia Alshanetsky wrote: > > […] > > Also @Antony Dovgal in the "let blocks" thread > > Short answer: No. > > The reason I posted my suggestions on this list was that a while ago I > had a few ideas as to how PHP could be improved. What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way? If there are no problems, then please don't improve anything not broken. "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine. -- Wbr, Antony Dovgal --- ## #31105 — David Coallier — 2007-07-19T17:09:29+00:00 URL: https://externals.io/message/31057#31105 · In reply to: #31103 > > > […] > > What I don't understand about the crypt thing you propose - is what problem are you trying to fix this way? > > If there are no problems, then please don't improve anything not broken. > "No reasons to keep it" is wrong, there is at least one reason to keep it as is - it works fine. > > -- > Wbr, > Antony Dovgal > > -- > > > > Here are three patches against HEAD [1], 5_2 [2] and the pecl repository [3] (Do not shout just yet, I'll explain). The idea of the patches are pretty simple, aliasing rand, srand, getrandmax to mt_rand, mt_srand, and mt_getrandmax. The goal is simply having a better number generation. Nothing fancier, or more different, but simply it. It works great (compiling great against 5_2, HEAD) and Crisitan Rodriguez also tried the compilation. After a bit of discussion with Jani, I came to realize that keeping the wrapper macro for php_rand, php_srand is plain useless. Yes some pecl extensions do rely on them (and for those who do, I also provided a patch [3]). We both realized that there's not many extensions relying on php_rand and php_srand thus removed it completely.. Here are the patches: [1] HEAD : http://dev.agoraproduction.com/php/php6/head-mt-changes.diff [2] 5_2 : http://dev.agoraproduction.com/php/5_2/5.2-mt-changes.diff [3] PECL : http://dev.agoraproduction.com/php/php6/pecl-mt-changes.diff Please note that the mt-changes patches are not only changing ext/standard/* but also the ext/* relying on them. (soap, mcrypt) but also a small change in main/reentrancy.c both in 5_2 and HEAD. Thanks, -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #31106 — David Coallier — 2007-07-19T17:26:34+00:00 URL: https://externals.io/message/31057#31106 · In reply to: #31105 > > > […] Sorry I did not quite answer your question in my email + patch. Yes it works correctly as it is, however, with this patch, the random numbers being generated are using an algorithm (Mersenne Twister) that allows us to give more randomness if I may use the term. So it simply doesn't *fix* anything, but improves random number generation. There are various reasons why people are using random generated numbers and mt_ is more random than rand*. Simply it. It does not **fix** something that is broken, simply improves it. Yes we could still use a rock to make fire, and it still works fine, but might as well use matches, lenses or lighters. It's more effective and faster. > > […] > > Here are three patches against HEAD [1], 5_2 [2] and the pecl > repository [3] (Do not shout just yet, I'll explain). > > The idea of the patches are pretty simple, aliasing rand, srand, > getrandmax to mt_rand, mt_srand, and mt_getrandmax. The goal is simply > having a better number generation. Nothing fancier, or more different, > but simply it. It works great (compiling great against 5_2, HEAD) and > Crisitan Rodriguez also tried the compilation. > > After a bit of discussion with Jani, I came to realize that keeping > the wrapper macro for php_rand, php_srand is plain useless. Yes some > pecl extensions do rely on them (and for those who do, I also provided > a patch [3]). We both realized that there's not many extensions > relying on php_rand and php_srand thus removed it completely.. > > Here are the patches: > > [1] HEAD : http://dev.agoraproduction.com/php/php6/head-mt-changes.diff > [2] 5_2 : http://dev.agoraproduction.com/php/5_2/5.2-mt-changes.diff > [3] PECL : http://dev.agoraproduction.com/php/php6/pecl-mt-changes.diff > > > Please note that the mt-changes patches are not only changing > ext/standard/* but also the ext/* relying on them. (soap, mcrypt) but > also a small change in main/reentrancy.c both in 5_2 and HEAD. > > Thanks, > > -- > David Coallier, > Founder & Software Architect, > Agora Production (http://agoraproduction.com) > 51.42.06.70.18 > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #31108 — johannes@php.net — 2007-07-19T17:50:41+00:00 URL: https://externals.io/message/31057#31108 · In reply to: #31105 Hi David, > After a bit of discussion with Jani, I came to realize that keeping > the wrapper macro for php_rand, php_srand is plain useless. Yes some > pecl extensions do rely on them (and for those who do, I also provided > a patch [3]). We both realized that there's not many extensions > relying on php_rand and php_srand thus removed it completely.. I don't think that removing APIs during a point release is a good thing. Even when you grepped through PECL it doesn't mean that not more extensions are using these functions. I'm fine with removing it from HEAD, if there's an replacement but not for a bugfix release. johannes --- ## #31109 — davidc@php.net — 2007-07-19T18:02:44+00:00 URL: https://externals.io/message/31057#31109 · In reply to: #31108 I totally agree. the only reasn for the 5-2 patch was for people to test > Hi David, > > > > […] > > I don't think that removing APIs during a point release is a good thing. > Even when you grepped through PECL it doesn't mean that not more > extensions are using these functions. I'm fine with removing it from > HEAD, if there's an replacement but not for a bugfix release. > > johannes > > -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 --- ## #31110 — Pierre — 2007-07-19T18:13:05+00:00 URL: https://externals.io/message/31057#31110 · In reply to: #31109 > I totally agree. the only reasn for the 5-2 patch was for people to test You can simply keep the old functions for 5.2 and remove them in HEAD. We can't remove an API (or change it) in a point release, it is a full breakage (BC and binary). --Pierre --- ## #31111 — David Coallier — 2007-07-19T18:21:21+00:00 URL: https://externals.io/message/31057#31111 · In reply to: #31110 > > > […] > > You can simply keep the old functions for 5.2 and remove them in HEAD. > > We can't remove an API (or change it) in a point release, it is a full > breakage (BC and binary). > > > --Pierre > I agree, this was mainly for HEAD, but just wanted to give an opportunity to people to test it. HEAD it is :) -- David Coallier, Founder & Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18