Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Another div case: ``` $num = new Number('0.01'); // scale 18 $num2 = new Number('3'); $div = $num->div($num2); $div->getNumber(); // '0.00' scale 18 $div = $num->div($num2, 20); $div->getNumber(); // '0.0033' scale 20 ``` Regards. Saki

Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath

Hi Jordan, > For addition, it absolutely should expand scale like this, unless the > constructor also defines a default rounding type that is used in that > situation. All numbers, while arbitrary, will be finite, so addition will > always be exact and known based on inputs prior to

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

On Sat, Mar 30, 2024 at 5:46 PM Ben Ramsey wrote: > On Mar 30, 2024, at 07:03, Jakub Zelenka wrote: > >  > Hi, > > On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta wrote: > >> >> >> On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote: >> >>> On Mar 29, 2024, at 20:20, Bob Weinand wrote: >>> >>>  >>>

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi, On Sat, Mar 30, 2024 at 3:33 PM Daniil Gentili wrote: > It is also pretty standard thing to distribute configure files (which is > the file that probably matters most). > > The current standard way of distributing generated configure files in > tarballs is precisely what allowed the xz

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

On Mar 30, 2024, at 07:03, Jakub Zelenka wrote:Hi,On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta wrote:On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote:On Mar 29, 2024, at 20:20, Bob Weinand wrote: On 29.3.2024 23:31:26,

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

That would break lots of tools as it requires extra dependencies so it is not something that would could in stable versions. Btw, I do not believe that "it would require end users to install autotools and bison in order to compile PHP from tarballs" is valid reason to delay the patching of

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi, It is also pretty standard thing to distribute configure files (which is the file that probably matters most). The current standard way of distributing generated configure files in tarballs is precisely what allowed the xz supply chain attack to go unnoticed for so long. I strongly

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

On Sat, Mar 30, 2024 at 12:03 PM Jakub Zelenka wrote: > Hi, > > On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta wrote: > >> >> >> On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote: >> >>> On Mar 29, 2024, at 20:20, Bob Weinand wrote: >>> >>>  >>> On 29.3.2024 23:31:26, Daniil Gentili wrote: >>> >>>

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi On Sat, Mar 30, 2024 at 1:39 PM Daniil Gentili wrote: > Hi, > > > >The idea is that we would setup worklfow on CI that would run on tag push > and it would call (authenticated https request) downloads.php.net server > that could do the actual build > > I strongly believe that source tarballs

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi On 3/30/24 14:20, Stanislav Malyshev wrote: But does the release manager generate the files (and the tarball) in a reproducible way? I understand that's what ./scripts/dev/makedist and ./scripts/dev/genfiles do, but I suspect exact bits in resulting configure and lexers may depend on the

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi, >The idea is that we would setup worklfow on CI that would run on tag push and it would call (authenticated https request) downloads.php.net server that could do the actual build I strongly believe that source tarballs should contain *only* the source code

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi! On 3/30/24 1:27 AM, Sebastian Bergmann wrote: Am 30.03.2024 um 05:17 schrieb Ben Ramsey: This is also why our release managers sign the tarballs with their own GPG keys, after generating the artifacts. This verifies the release manager was the one who generated the files. But does the

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Hi, On Sat, Mar 30, 2024 at 7:08 AM Marco Pivetta wrote: > > > On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote: > >> On Mar 29, 2024, at 20:20, Bob Weinand wrote: >> >>  >> On 29.3.2024 23:31:26, Daniil Gentili wrote: >> >> In light of the recent supply chain attack in xz/lzma, leading to a >>

Re: [PHP-DEV] [RFC] Invoke __callStatic when non-static public methods are called statically

On Sat, Mar 30, 2024 at 1:06 AM 하늘아부지 wrote: > > > > 2024년 3월 30일 (토) 오전 2:15, Robert Landers 님이 작성: >> >> On Fri, Mar 29, 2024 at 3:41 AM 하늘아부지 wrote: >> > >> > Hello. >> > >> > I created a wiki for __callStatic related issues. >> > Please see: >> >

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

Am 30.03.2024 um 05:17 schrieb Ben Ramsey: This is also why our release managers sign the tarballs with their own GPG keys, after generating the artifacts. This verifies the release manager was the one who generated the files. But does the release manager generate the files (and the tarball)

Re: [PHP-DEV] Consider removing autogenerated files from tarballs

On Sat, 30 Mar 2024, 05:19 Ben Ramsey, wrote: > On Mar 29, 2024, at 20:20, Bob Weinand wrote: > >  > On 29.3.2024 23:31:26, Daniil Gentili wrote: > > In light of the recent supply chain attack in xz/lzma, leading to a > backdoor in openSSH ( >