Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

2023-10-04 Thread Marc Bennewitz
Hi, On 03.10.23 14:41, Tim Düsterhus wrote: Hi On 9/30/23 08:26, Marc Bennewitz wrote: The deprecation would act as an information for upcoming behavior change, not classical deprecation of future removal. If the new behavior is what you want, than you don't need to change anything as a

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

2023-10-04 Thread Saki Takamachi
Hi, Marc, Pierre Thank you for all the information. After all, I feel that BCMath and GMP have different roles. Arbitrary precision mathematics and very high precision mathematics are similar but distinctly different. If PHP has already started integrating these things, then of course I'll

[PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

2023-10-04 Thread Jorg Sowa
Thank you all for the discussion. I modified description of the RFC and added deprecation of constants ROUND_UP and ROUND_DOWN from Intl extension as an additional voting. Thanks also for input about possible mode ROUND_STOCHASTIC, however I think it's the idea for the extension and not the

Re: [PHP-DEV] Re: [RFC] [Discussion] Add 4 new rounding modes to round() function

2023-10-04 Thread G. P. B.
On Wed, 4 Oct 2023 at 23:23, Jorg Sowa wrote: > Thank you all for the discussion. I modified description of the RFC and > added deprecation of constants ROUND_UP and ROUND_DOWN from Intl extension > as an additional voting. > > Thanks also for input about possible mode ROUND_STOCHASTIC, however

Re: [PHP-DEV] [RFC] [Discussion] Rounding Integers as int

2023-10-04 Thread G. P. B.
On Tue, 26 Sept 2023 at 11:39, Marc Bennewitz wrote: > Hi internals > > I'd like to put a new RFC under discussion: > https://wiki.php.net/rfc/integer-rounding I don't understand the point of the deprecation phase at all. Frankly, I consider this RFC a bug fix of the current "broken"

Re: [PHP-DEV] proc_open() resource to opaque object migration

2023-10-04 Thread G. P. B.
On Thu, 28 Sept 2023 at 21:20, Máté Kocsis wrote: > Hi Everyone, > > I'm writing in connection with a question coming up lately during the > "resource to opaque object migration" project ( > https://github.com/php/php-tasks/issues/6) which we have been working on > for quite a long while. > >

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

2023-10-04 Thread steve
I know I'm late but bcrypt cost 12 (which looks like the winner) is high. Cost 12 is ~1 kH/s/GPU and the accepted limit for good settings is <10 kH/s/GPU. Cost 12 is 10x stronger than it needs to be as a *minimum*. I believe cost 10 is a good *default* for the next 1-3 years and cost 11 should

Re: [PHP-DEV] [VOTE] Increasing the default BCrypt cost

2023-10-04 Thread steve
> On 09/22/2023 2:04 AM CDT Nicolas Grekas wrote: > > > I was wondering if you considered also raising the Argon2 default cost? Has > this been discussed? > Argon2 defaults are actually quite high at a theoretical speed of ~1.3 kH/s/GPU (960,000,000,000/(64*1024^2)/(3*4-1) or in general

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

2023-10-04 Thread Pierre Joye
Hi On Wed, Oct 4, 2023, 6:39 PM Saki Takamachi wrote: > Hi, Marc, Pierre > > Thank you for all the information. > > After all, I feel that BCMath and GMP have different roles. > > Arbitrary precision mathematics and very high precision mathematics are > similar but distinctly different. > I

Re: [PHP-DEV] RFC: Increasing the default BCrypt cost

2023-10-04 Thread steve
> On 09/07/2023 4:37 PM CDT Craig Francis wrote: > > We recently discussed hashing and costs at one of our OWASP meetings, we came > to conclusion that the default of 10 for bcrypt probably should be increased, > but only to 11 for typical websites. The main concern was about making >