Re: [PHP-DEV] FFI [was: Breakages with rc1]

[Dusk]

On Sep 6, 2023, at 19:18, Hanz  wrote:
> On a totally different note... I'm trying to get my head around FFI
>  specifically how it could be
> used to orchestrate 3rd party pipelines, like those of python.

That isn't a particularly good use case for FFI. If you're trying to call 
Python scripts, you're probably looking for popen(), proc_open(), or something 
like the Symfony Process component (composer require symfony/process).

FFI allows PHP scripts to load and call functions in C libraries. This can 
allow PHP scripts to access functionality which doesn't have PHP wrappers 
available.

If you're on macOS, here's a silly but functional example which calls the 
NSBeep() function to make your computer beep:

$ffi = FFI::cdef(<<<'EOF'
void NSBeep(void);
EOF, "@rpath/AppKit.framework/AppKit");
$ffi->NSBeep();
sleep(1);

(Don't worry too much about the @rpath bit.)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] FFI [was: Breakages with rc1]

[Hanz]

Hi Peter, Niels,

On Tue, Sep 5, 2023 at 3:08 PM Peter Kokot  wrote:
>
> On Tue, 5 Sept 2023 at 11:40, Hanz  wrote:
>>
>> Hello,
>>
>> Ran into a couple of issues with RC1 that I haven't seen online.
>>
>> With --with-pear: The --with-pear option is deprecated
>>
>> With --enable-pear: configure: WARNING: unrecognized options:
--enable-pear
>>
>> I'm using --disable-all as the first parameter.
>
>
> There is only --with-pear option and when used it simply emits a warning
since PHP 7.4 to make it clear that in one of the future PHP versions PEAR
won't be installed via PHP build process anymore.
>
> It still works though.

Thanks much for this and the opcache pointers - got it all set.

On a totally different note... I'm trying to get my head around FFI
 specifically how it could be
used to orchestrate 3rd party pipelines, like those of python.  Anyone
aware of anyone using this extension, examples, etc?

Thanks again!

---
Hans Z.
http://nyphp.org

[PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Niels Dossche]

Hi Dennis

On 06/09/2023 22:02, Dennis Snell wrote:
> 
> 
>> On Sep 4, 2023, at 1:15 PM, Niels Dossche  wrote:
>>
>> On 04/09/2023 21:54, Dennis Snell wrote:
>>> Thanks for the proposal Niels,
>>>
>>> I’ve dealt with my own grief working through issues in DOMDocument and 
>>> wanting it to work but finding it inadequate.
>>>
 HTML5
>>>
>>> This would be a great starting point; I would love it if we took the 
>>> opportunity to fix named character reference decoding, as PHP has (to my 
>>> knowledge) never respected (at least in HTML5) that they decode differently 
>>> inside attributes as they do inside markup, considering rules such as the 
>>> ambiguous ampersand and decode errors.
>>>
>>> It’s also been frustrating that DOMDocument parses tags in RCDATA sections 
>>> where they don’t exist, such as in TITLE or TEXTAREA elements, escapes 
>>> certain types of invalid comments so that they appear rendered in the saved 
>>> document, and misses basic semantic rules (e.g. creating a BUTTON element 
>>> as a child of a BUTTON element instead of closing out the already-open 
>>> BUTTON).
>>
>> With this proposal: a real HTML5 parser, these above mentioned problems will 
>> fortunately be a problem from the past :)
> 
> Awesome. Makes me happy as long as we’re looking at a wholesale replacement 
> of the foundations upon which `DOMDocument` are built. My comment was mostly 
> to point out that there are levels to the inadequacy of `DOMDocument`; or 
> phrased differently, I support diverging from the `DOMDocument` class and 
> parser and even the interface. Making a break from the expectations of the 
> existing one could be nice to signal that it’s different, though I see that 
> full backwards compatibility is important to you.
> 

I had a productive discussion with Tim this week about diverging from the 
interface to offer a nicer API.
It's highly possible I'll propose a change to the RFC later this week to make 
the API a bit cleaner, which will also signal that it's different. The 
backwards compatibility aspect will largely remain however. Especially the 
requirement that it should be opt-in is important to me.

>>
>>>
>>> I’d like to share some what a few of us have been working on inside 
>>> WordPress, which is to build a conformant streaming HTML5 parser:
>>>  - https://developer.wordpress.org/reference/classes/wp_html_tag_processor/ 
>>> 
>>>  - https://make.wordpress.org/core/2023/08/19/progress-report-html-api/ 
>>> 
>>>
>>> It’s just food for thought right now because adding HTML5 support to 
>>> DOMDocument would benefit everyone, but we decided we had common need in 
>>> PHP to work with HTML not in a DOM, but in a streaming fashion, one with 
>>> very little runtime overhead. My long-term plan has been to get a good 
>>> grasp for the interface needs and thoroughly test it within the WordPress 
>>> community and then propose its inclusion into PHP. It’s been incredibly 
>>> handy so far, and on my laptop runs at around 20 MB/s, which is not great, 
>>> but good enough for many needs. My naive C port runs on the same laptop at 
>>> around 80 MB/s and I believe that we can likely triple or quadruple that 
>>> speed again if any of us working on it knew how to take advantage of SIMD 
>>> instrinsics.
>>>
>>> It tries to accomplish a few goals:
>>>  - be fast enough
>>>  - interpret HTML as an HTML5-compliant browser will
>>>  - find specific locations within an HTML document and then read or modify 
>>> them
>>>  - pass through any invalid HTML it encounters for the browser to 
>>> resolve/fix unless modifying the part of the document containing those 
>>> invalid constructions
>>>
>>
>> I've seen someone link this on Reddit today, it's a really nice project!
>> It reminds me of Cloudflare's lol-html, which is also a streaming parser 
>> used to modify and sanitize documents linearly.
>> I believe this could be a great addition, it solves a different problem that 
>> the ext/dom extension solves. So I think it would be a great complementary 
>> addition.
> 
> Unfortunately we only found the Cloudflare project after building our “Tag 
> Processor” but the similarities are striking. Having this kind of interface 
> inside PHP would do wonders for the WordPress world, and I think it would be 
> great for many other projects.
> 

Absolutely!

>>
>>> I only bring up this different interface because once we started digging 
>>> deep into DOMDocument we found that the problems with it were far from 
>>> superficial; that there is a host of problems and a mismatched interface to 
>>> our common needs. It has surprised me that PHP, the language of the web, 
>>> has had such trouble handling HTML, the language of the web, and we wanted 
>>> to completely resolve this issue once and for all within WordPress so we 
>>> can clean up decades’ old problems with 

[PHP-DEV] Re: [RFC] [Discussion] DOM HTML5 parsing and serialization support

[Dennis Snell via internals]

> On Sep 4, 2023, at 1:15 PM, Niels Dossche  wrote:
> 
> On 04/09/2023 21:54, Dennis Snell wrote:
>> Thanks for the proposal Niels,
>> 
>> I’ve dealt with my own grief working through issues in DOMDocument and 
>> wanting it to work but finding it inadequate.
>> 
>>> HTML5
>> 
>> This would be a great starting point; I would love it if we took the 
>> opportunity to fix named character reference decoding, as PHP has (to my 
>> knowledge) never respected (at least in HTML5) that they decode differently 
>> inside attributes as they do inside markup, considering rules such as the 
>> ambiguous ampersand and decode errors.
>> 
>> It’s also been frustrating that DOMDocument parses tags in RCDATA sections 
>> where they don’t exist, such as in TITLE or TEXTAREA elements, escapes 
>> certain types of invalid comments so that they appear rendered in the saved 
>> document, and misses basic semantic rules (e.g. creating a BUTTON element as 
>> a child of a BUTTON element instead of closing out the already-open BUTTON).
> 
> With this proposal: a real HTML5 parser, these above mentioned problems will 
> fortunately be a problem from the past :)

Awesome. Makes me happy as long as we’re looking at a wholesale replacement of 
the foundations upon which `DOMDocument` are built. My comment was mostly to 
point out that there are levels to the inadequacy of `DOMDocument`; or phrased 
differently, I support diverging from the `DOMDocument` class and parser and 
even the interface. Making a break from the expectations of the existing one 
could be nice to signal that it’s different, though I see that full backwards 
compatibility is important to you.

> 
>> 
>> I’d like to share some what a few of us have been working on inside 
>> WordPress, which is to build a conformant streaming HTML5 parser:
>>  - https://developer.wordpress.org/reference/classes/wp_html_tag_processor/ 
>> 
>>  - https://make.wordpress.org/core/2023/08/19/progress-report-html-api/ 
>> 
>> 
>> It’s just food for thought right now because adding HTML5 support to 
>> DOMDocument would benefit everyone, but we decided we had common need in PHP 
>> to work with HTML not in a DOM, but in a streaming fashion, one with very 
>> little runtime overhead. My long-term plan has been to get a good grasp for 
>> the interface needs and thoroughly test it within the WordPress community 
>> and then propose its inclusion into PHP. It’s been incredibly handy so far, 
>> and on my laptop runs at around 20 MB/s, which is not great, but good enough 
>> for many needs. My naive C port runs on the same laptop at around 80 MB/s 
>> and I believe that we can likely triple or quadruple that speed again if any 
>> of us working on it knew how to take advantage of SIMD instrinsics.
>> 
>> It tries to accomplish a few goals:
>>  - be fast enough
>>  - interpret HTML as an HTML5-compliant browser will
>>  - find specific locations within an HTML document and then read or modify 
>> them
>>  - pass through any invalid HTML it encounters for the browser to 
>> resolve/fix unless modifying the part of the document containing those 
>> invalid constructions
>> 
> 
> I've seen someone link this on Reddit today, it's a really nice project!
> It reminds me of Cloudflare's lol-html, which is also a streaming parser used 
> to modify and sanitize documents linearly.
> I believe this could be a great addition, it solves a different problem that 
> the ext/dom extension solves. So I think it would be a great complementary 
> addition.

Unfortunately we only found the Cloudflare project after building our “Tag 
Processor” but the similarities are striking. Having this kind of interface 
inside PHP would do wonders for the WordPress world, and I think it would be 
great for many other projects.

> 
>> I only bring up this different interface because once we started digging 
>> deep into DOMDocument we found that the problems with it were far from 
>> superficial; that there is a host of problems and a mismatched interface to 
>> our common needs. It has surprised me that PHP, the language of the web, has 
>> had such trouble handling HTML, the language of the web, and we wanted to 
>> completely resolve this issue once and for all within WordPress so we can 
>> clean up decades’ old problems with encoding, decoding, security, and 
>> sanitization.
> 
> Yes, I was also quite surprised of the lacking support for modern web 
> features, and also the problems with spec compliance.
> I only recently got into maintaining ext/dom. So there's still a lot of work 
> to do.
> I had already started with adding more DOM APIs in the 8.3 release cycle and 
> plan to continue that effort in 8.4.
> Another major project I want to do for 8.4, besides HTML5 support, is fixing 
> the spec compliance issues in an opt-in manner. This would help with security 
> & 

Re: [PHP-DEV] PASSWORD_DEFAULT value

[Vinicius Dias]

This is very interesting. It's the first time I see recommendations
pro Bcrypt and against Argon2. Even Owasp recommends Argon2 over
Bcrypt [1].

I am not a cryptography expert so I believe that if there is a
discussion of which one is better PHP shouldn't change things for now,
so that totally answers the question of why the default is still
bcrypt.

Thank you both for replying.

[1] 
https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html



Vinicius Dias,
Zend Certified Engineer,
iMasters PHP Certified Professional




Em qua., 6 de set. de 2023 às 16:25, Hans Henrik Bergan
 escreveu:
>
> Argon2 is opt-in, not opt-out, at compile-time, so then we would have to 
> agree on it being acceptable for PASSWORD_DEFAULT to have different values 
> depending on compile-time options, maybe thats completely fine, or maybe it 
> isn't, idk.
>
> But as Dusterhus points out, Argon2 is inferior to bcrypt anyway, according 
> to people much smarter than myself.
>
> Oh and Argon2 has been around since 2015 and multiple vulnerabilities have 
> been discovered, speeding up brute force/dictionary attacks. Can't say the 
> same for bcrypt
>
> On Wed, Sep 6, 2023, 18:52 Tim Düsterhus  wrote:
>>
>> Hi
>>
>> On 9/6/23 18:08, Vinicius Dias wrote:
>> > I was wondering here... Is there any reason for `PASSWORD_DEFAULT`'s
>> > value not to be `PASSWORD_ARGON2ID`?
>> >
>>
>> To the best of my knowledge Argon2 is not available in a "default"
>> installation of PHP without including any external dependencies.
>>
>> Also Argon2 for settings that are reasonable for interactive
>> authentication is worse than BCrypt according to:
>>
>> https://twitter.com/TerahashCorp/status/1155119064248913920
>> and
>> https://twitter.com/TerahashCorp/status/1155129705034653698
>>
>> Best regards
>> Tim Düsterhus
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: https://www.php.net/unsub.php
>>

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PASSWORD_DEFAULT value

[Hans Henrik Bergan]

Argon2 is opt-in, not opt-out, at compile-time, so then we would have to
agree on it being acceptable for PASSWORD_DEFAULT to have different values
depending on compile-time options, maybe thats completely fine, or maybe it
isn't, idk.

But as Dusterhus points out, Argon2 is inferior to bcrypt anyway, according
to people much smarter than myself.

Oh and Argon2 has been around since 2015 and multiple vulnerabilities have
been discovered, speeding up brute force/dictionary attacks. Can't say the
same for bcrypt

On Wed, Sep 6, 2023, 18:52 Tim Düsterhus  wrote:

> Hi
>
> On 9/6/23 18:08, Vinicius Dias wrote:
> > I was wondering here... Is there any reason for `PASSWORD_DEFAULT`'s
> > value not to be `PASSWORD_ARGON2ID`?
> >
>
> To the best of my knowledge Argon2 is not available in a "default"
> installation of PHP without including any external dependencies.
>
> Also Argon2 for settings that are reasonable for interactive
> authentication is worse than BCrypt according to:
>
> https://twitter.com/TerahashCorp/status/1155119064248913920
> and
> https://twitter.com/TerahashCorp/status/1155129705034653698
>
> Best regards
> Tim Düsterhus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

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

[Tim Düsterhus]

Hi

On 9/5/23 00:34, Jorg Sowa wrote:

Introducing a brand-new RoundingMode enum (using union types) I
suggested in my first email would nicely solve the naming problem and
would also make the API more obvious to use due to stronger typing in
the long run.


That's also interesting idea and I would push it, however I'm afraid about
the naming of namespace. I recollect some of the RFCs were rejected simply



I didn't intent to suggest putting the enum into a namespace. It would 
be `\RoundingMode` (i.e. within the global namespace). I'm not sure how 
you got the impression I suggest a namespace.



because of the namespace. If there is a guideline for the namespace of core
functions I would willingly get familiar to it. Otherwise, I don't want to



For the reference, there is a namespace guideline here: 
https://wiki.php.net/rfc/namespaces_in_bundled_extensions


It doesn't really apply here, because `round()` is in ext/standard.


open Pandora box only because of the namespace of Enum. It would also bring
BC to the function, unless we would accept both enum and old constants.



Yes it would accept both the enum and the constants. In the long run the 
constants could be deprecated. Alternatively the constants could be 
aliases for the enum values, but this might break compatibility for 
users that use the raw integers instead of the constants. While this is 
"not a good idea", it might have happened.


Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PASSWORD_DEFAULT value

[Tim Düsterhus]

Hi

On 9/6/23 18:08, Vinicius Dias wrote:

I was wondering here... Is there any reason for `PASSWORD_DEFAULT`'s
value not to be `PASSWORD_ARGON2ID`?



To the best of my knowledge Argon2 is not available in a "default" 
installation of PHP without including any external dependencies.


Also Argon2 for settings that are reasonable for interactive 
authentication is worse than BCrypt according to:


https://twitter.com/TerahashCorp/status/1155119064248913920
and
https://twitter.com/TerahashCorp/status/1155129705034653698

Best regards
Tim Düsterhus

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

[Larry Garfield]

On Wed, Sep 6, 2023, at 2:53 PM, Kamil Tekiela wrote:
>>Do you think there is still demand for such error mode control features?
>>
>>Personally, I've never seen anyone prefer silent mode, so I think it's worth 
>>making the drastic change.
>
> This may be right. There isn't a demand for this in **new** code and I
> doubt anyone would come forward with a reason to use silent mode now.
> However the purpose of keeping this mode is to enable old legacy code
> to run without major refactoring. This is the practice coming from the
> days before PHP 5 when using exceptions wasn't common. Plenty of
> applications are still running code designed 20 years ago because PHP
> keeps as much backward compatibility as possible. The code would
> benefit from modernization, but this would require a lot of effort
> from its maintainers.
>
> We may get away with deprecating and removing PDO silent/warning mode
> because it's an extension that was introduced in PHP 5 and everyone
> was on board with using exception mode. We probably cannot remove
> silent mode for other extensions that either mimic older extensions
> that didn't use exceptions (e.g. mysqli) or have been introduced
> before PHP 5. The reason is that people designed their code using
> silent mode and removing it now would cause some serious headaches.
>
> Another point to consider is that PDO had silent mode as default for a
> long time. You may be surprised, but many people weren't aware that it
> can throw exceptions. My guess is that's a very small proportion of
> all projects though. With PHP 8.0, they just slapped one line of code
> and called it a day. Having said that, I think removing PDO's silent
> mode is possible soon, even in PHP 9.0, but we may anger some people.
>
> All warning modes can be deprecated in PHP 8.4 and removed in PHP 9.0.
> Silent mode of other extensions should be carefully reviewed one by
> one. Deprecation in PHP 9.0 and removal in PHP 10.0 might be a better
> option.

I would also be fine with deprecating and removing the old/useless error modes, 
but only if there's a long enough deprecation period.  I question if 8.4->9 
would be sufficient.  I'd be more comfortable with deprecating them now and 
removing in 10.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

[Saki Takamachi]

> We may get away with deprecating and removing PDO silent/warning mode because 
> it's an extension that was introduced in PHP 5 and everyone was on board with 
> using exception mode. We probably cannot remove silent mode for other 
> extensions that either mimic older extensions that didn't use exceptions 
> (e.g. mysqli) or have been introduced before PHP 5. The reason is that people 
> designed their code using silent mode and removing it now would cause some 
> serious headaches.


> Another point to consider is that PDO had silent mode as default for a long 
> time. You may be surprised, but many people weren't aware that it can throw 
> exceptions. My guess is that's a very small proportion of all projects though.
> With PHP 8.0, they just slapped one line of code and called it a day. Having 
> said that, I think removing PDO's silent mode is possible soon, even in PHP 
> 9.0, but we may anger some people.

> All warning modes can be deprecated in PHP 8.4 and removed in PHP 9.0.
> Silent mode of other extensions should be carefully reviewed one by one. 
> Deprecation in PHP 9.0 and removal in PHP 10.0 might be a better option.

I see.
Certainly, it seems necessary to consider the silent mode of other extensions 
enough. Agree.

This was originally a proposal to solve the situation where PDO's error mode 
behavior was not well maintained.

There are problems such as warnings being displayed even in silent mode, and 
correct information not being obtained using PDO::errorInfo.

It seems like a good option would be to keep all silent modes and deprecate 
warning mode in 8.4 and remove it in 9.x.
And it seems good to fix PDO's silent mode bug in 8.4.

What do you think?

Regards.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] PASSWORD_DEFAULT value

[Vinicius Dias]

Hey there, folks!

I was wondering here... Is there any reason for `PASSWORD_DEFAULT`'s
value not to be `PASSWORD_ARGON2ID`?

Would that change require an RFC?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

[Kamil Tekiela]

>Do you think there is still demand for such error mode control features?
>
>Personally, I've never seen anyone prefer silent mode, so I think it's worth 
>making the drastic change.

This may be right. There isn't a demand for this in **new** code and I
doubt anyone would come forward with a reason to use silent mode now.
However the purpose of keeping this mode is to enable old legacy code
to run without major refactoring. This is the practice coming from the
days before PHP 5 when using exceptions wasn't common. Plenty of
applications are still running code designed 20 years ago because PHP
keeps as much backward compatibility as possible. The code would
benefit from modernization, but this would require a lot of effort
from its maintainers.

We may get away with deprecating and removing PDO silent/warning mode
because it's an extension that was introduced in PHP 5 and everyone
was on board with using exception mode. We probably cannot remove
silent mode for other extensions that either mimic older extensions
that didn't use exceptions (e.g. mysqli) or have been introduced
before PHP 5. The reason is that people designed their code using
silent mode and removing it now would cause some serious headaches.

Another point to consider is that PDO had silent mode as default for a
long time. You may be surprised, but many people weren't aware that it
can throw exceptions. My guess is that's a very small proportion of
all projects though. With PHP 8.0, they just slapped one line of code
and called it a day. Having said that, I think removing PDO's silent
mode is possible soon, even in PHP 9.0, but we may anger some people.

All warning modes can be deprecated in PHP 8.4 and removed in PHP 9.0.
Silent mode of other extensions should be carefully reviewed one by
one. Deprecation in PHP 9.0 and removal in PHP 10.0 might be a better
option.

Regards,
Kamil

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

[Saki Takamachi]

> However, if we are going to remove it, it would be nice to have this done 
> consistently across all bundled extensions.

Thank you for confirmation.

This is probably not technically difficult, but it does increase the scope of 
change. However, as you say, the specifications should be unified.

Do you think there is still demand for such error mode control features?

Personally, I've never seen anyone prefer silent mode, so I think it's worth 
making the drastic change.

regards.

Saki
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Deprecate PDO::ATTR_ERRMODE [Proposed RFC]

[G. P. B.]

On Tue, 29 Aug 2023 at 14:52, Saki Takamachi  wrote:

> Hi, internals.
>
> I thought about various things to improve the current situation where
> `PDO::ATTR_ERRMODE` is not working very smartly.
>
> Exceptions may be thrown regardless of the setting of `PDO::ATTR_ERRMODE`.
> https://www.php.net/manual/en/pdo.rollback.php#refsect1-pdo.rollback-errors
>
> Another annoyance is that `PDO::ERRMODE_SILENT` sometimes gives a warning.
> This is an undocumented phenomenon, and it's a 19-year-old vintage bug.
>
> https://github.com/php/php-src/blob/223fb08819967b3063610289a5783944a85d6d65/ext/pdo/pdo_dbh.c#L74
>
> Based on these, I feel that the reliability of the attribute value
> PDO::ATTR_ERRMODE is low and there is not much meaning in its existence as
> an attribute value.
>
> Since the default behavior became `PDO::ERRMODE_EXCEPTION` in PHP8.0.0, I
> think it would be better to abolish it rather than leave it halfway.
>
> I think this is a big change, so I'm assuming 9.x+ even if it's
> implemented.
> I will do the implementation myself.
>
> Please let me know what you think.
> Thank you.
>
> Saki
>

I don't know about removing the silent mode altogether, but I think the
warning version is pretty useless.
However, if we are going to remove it, it would be nice to have this done
consistently across all bundled extensions.
>From the top of my head, I know SQLite3 and the Intl extension also have
such flags, and possibly the DOM extension too.

Best regards.

George P. Banyard