Re: [PHP-DEV] Requiring GPG Commit Signing

[Ayesh Karunaratne]

>
> Hi,
>
> What do y'all think about requiring GPG signed commits for the php-src
> repository?
>
> I had a look, and this is also something we can enforce through GitHub
> as well (by using branch protections).
>
> cheers,
> Derick
>
>
> --
> https://derickrethans.nl | https://xdebug.org | https://dram.io
>
> Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
>
> mastodon: @derickr@phpc.social @xdebug@phpc.social

+1 from me as well, and quite good timing with all the xz fiasco just last week.

Git can also sign with SSH keys now, so this is now merely a config update

Re: [PHP-DEV][RFC] grapheme cluster for str_split, grapheme_str_split function

[Ayesh Karunaratne]

>
> 2024年3月9日(土) 15:26 youkidearitai :
> >
> > Hello, Internals
> >
> > I created an wiki for `grapheme_str_split` function.
> > Please see:
> > https://wiki.php.net/rfc/grapheme_str_split
> >
> > I would like to "Under Discussion" section.
> >
> > Best Regards
> > Yuya
> >
> > --
> > ---
> > Yuya Hamada (tekimen)
> > - https://tekitoh-memdhoi.info
> > - https://github.com/youkidearitai
> > -
>
> Hello, Internals
>
> I want to go to "Voting" phase if nothing any comment.
> I will start at tomorrow(26th) to "Voting" phase.
>
> Thank you
> Yuya
>
> --
> ---
> Yuya Hamada (tekimen)
> - https://tekitoh-memdhoi.info
> - https://github.com/youkidearitai
> -

I think it makes sense to add this function, and the PR worked well
too; It correctly split individual graphemes for all comlex Emojis,
ZWJs, and those Cthulu texts, and everything else I threw at it.

Good luck for the RFC vote today, hope it passes 爛.

Re: [PHP-DEV] [RFC] [Discussion] Deprecate GET/POST sessions

[Ayesh Karunaratne]

>
> Hi Internals,
>
> I would like to start a discussion on a new RFC
> https://wiki.php.net/rfc/deprecate-get-post-sessions
>
> Please let me know whether the idea is clear and the RFC is understandable.
>
> In particular, I am looking for any feedback as to why this is a bad
> idea. The primary motivation behind this RFC is to reduce potential
> security pitfalls.
>
> Regards,
> Kamil Tekiela

Hi Kamil,

I quite like the idea, and I think the RFC motivation, impact, and the
scope is clear as well.

The PHP 8.4 deprecations RFC also proposes to deprecate SID constant;
perhaps it's something worth mentioning in this RFC too?

Re: [PHP-DEV] int|float for sleep? sleep(0.1) => sleep 0.1 seconds

[Ayesh Karunaratne]

>
> Made a RFC draft: https://wiki.php.net/rfc/sleep_function_float_support
>
> First time, so I'm not surprised if there are some mistakes there.
>
> Feedback is very welcome.
>

Hi Hans,
The RFC looks great, and I am personally positive to see these proposed
changes implemented in PHP.

One suggestion I have is to simplify the six votes to three, each with
three options:

 - Disagree the proposal
 - Agree to implement in PHP 8.4
 - Agree to implement in PHP 9.0

I think it's also helpful if the PR link was added to the top of the RFC,
ideally next to the "First Published at". Most RFCs also remove the
sections that don't apply to them (such as Future Scope section).

That said, thanks for making this, it's something I'd like to see in PHP as
well.

Re: [PHP-DEV] int|float for DateTime::setTimestamp

[Ayesh Karunaratne]

>
> just like the constructor accepts
> new DateTime("@0.123456"); // 1970-01-01 00:00:00.123456
> new DateTime("@".microtime(true));
>
> IMO setTimestamp should accept the same:
> $dt->setTimestamp(0.123456); // 1970-01-01 00:00:00.123456
> $dt->setTimestamp(microtime(true));
>
> Can we change setTimestamp to accept int|float?
> made a PR https://github.com/php/php-src/pull/13383

You are probably already aware, but PHP 8.4 will have a new
`DateTime::get/setMicroseconds` method[^1][^2] that accepts an integer
microsecond value.

That said, I personally think it makes sense to accept float values
for fractions of seconds, but changing the parameter type WILL be be a
BC break because all subclasses extending `setTimestamp` will not be
compatible unless they are changed to `int|float` or wider.


[^1]: 
https://github.com/php/php-src/commit/0016b3085cf06e8a189ecc53c31697e3a108dbdd
[^2]: https://php.watch/versions/8.4/date-datetime-get-setMicroseconds

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

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Ayesh Karunaratne]

> > I see. I'll change mb_ucfirst using titlecase.
>
> Per my comments a month ago on the GitHub issue , I think it is much
> better to use title case for mb_ucfirst() than to use upper case,
> since conversion of the first character to upper case has the effect
> of corrupting text in the Georgian script, and initial lower-case
> ligatures are converted to a form which appears like two upper case
> letters. So I'm pleased to see this change to the PR.
>
> I would appreciate it if the RFC could also be updated to include this
> detail, since my vote depends on whether title case or upper case will
> be used.
>
> -- Tim Starling
>

Hi Tim,
Now that the RFC is restarted, could you mention some examples in Georgian
that might be good test cases?

I was thinking there might be some good test cases in Turkish, but couldn't
find any. The RFC has examples (https://github.com/php/php-src/pull/13161)
in Vietnamese, but they are correct for both "uppercase first character"
and titlecase conversions.

Thank you.

>

Re: [PHP-DEV][VOTE][RFC] mb_ucfirst and mb_lcfirst functions

[Ayesh Karunaratne]

>
> On Fri, Feb 2, 2024 at 2:00 AM youkidearitai 
> wrote:
>
> > Hi, Internals
> >
> > I have just opened the voting "Multibyte ucfirst and lcfirst functions"
> > RFC.
> > https://wiki.php.net/rfc/mb_ucfirst
> >
> > Voting will be open until February 26th, 2024 at 01:00 UTC.
> >
> > Cheers
> > Yuya
> >
> > --
> > ---
> > Yuya Hamada (tekimen)
> > - https://tekitoh-memdhoi.info
> > - https://github.com/youkidearitai
> > -
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: https://www.php.net/unsub.php
> >
> >
> In the proposal part is mentioned "From what I've researched with Unicode,
> it may not behave as expected in some languages. In that case, please deal
> with it in userland.". If my understanding here is wrong, please correct
> me. ucfirst and lcfirst are to uppercase/lowercase the first character of a
> word for characters that have an upper/lower case variant. Whether or not a
> word _should_ have an uppercase or lower case character is not important
> and currently doesn't behave in such a way for ucfirst and lcfirst. To me
> this isn't unexpected behavior, that's exactly how I would expect it to
> behave.
>

I think the author refers to the potential edge cases in certain Unicode
mappings. There isn't an ucfirst  mapping, but there are uppercase and
titlecase mappings.

Unicode titlecase mapping is different from uppercase mapping. This PR
seems to be using uppercase mapping. This should not matter for a vast
majority of characters, except for ligatures and digraphs.

I'm not at all and expert in these edge cases, but I just wanted to put my
two cents forth that I personally think using titlecase mapping on the
first word would be the more appropriate approach.

Thank you.

>

Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type

[Ayesh Karunaratne]

>
> I just encountered this language inconsistency when trying to remove
> nullable from a constructor-promoted property:
>
> ```
> class MyClass
> {
> public function __construct(
> public ?string $title = null // removing "?" here causes "Fatal
> error: Cannot use null as default value"
> ) {
>$this->title = $title ?: resolveTitle();
> }
> }
> ```
>
> Which is fine, there's a simple workaround, it was just surprising.

Property types don't infer nullability from the default value being
null, so constructor properties don't allow it either. I'd say this is
not an inconsistency, but rather a *consistency* with what this RFC
proposes to deprecate and remove.

Highly supportive of this RFC :)

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

Re: [PHP-DEV] Filesystem path APIs

[Ayesh Karunaratne]

>
> There could be OOP-style alternatives too, e.g. Rust has a PathBuf struct 
> with methods that are used to build paths.
> However if we were to choose this route then we need to be aware that 
> interoperability with existing filesystem functions would be much harder 
> because they all work directly with strings at the moment.
>

I think we really could use such an API. I would have liked a more
OOP-style approach, because it can impactfully "consolidate" various
functions into one.
I really like NodeJS Path class (https://nodejs.org/api/path.html),
which I think have done a really nice job at making it simple while
being quite versatile even for remote system paths.

In PHP land, the now-abandoned path-util
(https://packagist.org/packages/webmozart/path-util) library also had
an intuitive API.

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

Re: [PHP-DEV] Deprecate declare(encoding='...') + zend.multibyte + zend.script_encoding + zend.detect_unicode ?

[Ayesh Karunaratne]

> Shift_JIS is very ambiguous, What will we do if SJIS-2004 or SJIS-win comes?
> How do we guess(detect) SJIS-2004, SJIS-win and SJIS-mac?

I'm not the person you replied to in your previous email, but I
thought to weigh in with what I can. My native language also uses
multiple bytes, and have done a fair bit of character encoding
conversions from one to another.

The very reason why we have character encoding sets is to be able to
reassign the same byte values to multiple real-life characters, so
changing the character encodings from a non-UTF charset always carries
some sort of "risk" of detecting the wrong source text encoding. Like
Yuya Hamada mentioned in the rest of the previous email, 0xFC40 for
example can map to two different characters. These are quite common
occurrences, and there is even a word (Mojibake) for it!

The most robust projects in this space are probably `enca` and
`Chardet` (Python). However, theoretically, all tools can only guess
the text encoding by inspecting common patterns and by checking if all
bytes map to a meaningful glyph. When there is not a lot of text to
inspect, these tools are very prone to make wrong results.

When the source encoding is correctly detected or known, it's easy to
re-encode files using `iconv`, followed by a quick `sed` to remove the
`declare()` calls.

---

That said, I'm hugely in favor of dropping support for non-UTF8
encodings. Because the source encoding is present in the INI settings
or the declare statement, the site owners should be able to
mass-encode text to UTF-8. Many languages like Rust only support UTF-8
(https://doc.rust-lang.org/reference/input-format.html), and I don't
think any new PHP developers will expect PHP to work with non-UTF8
encodings in the first place.

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

Re: [PHP-DEV] What is the prevailing sentiment about extract() and compact() ?

[Ayesh Karunaratne]

>
> try {
>   // do stuff
> } catch(Throwable $exception) {
>   $this->logger->error("failed to do stuff", compact('exception'));
>   throw $exception;
> }
>

I wonder why not just create an array with the key...

```php
try {
   // do stuff
} catch(Throwable $exception) {
   $this->logger->error("failed to do stuff", ['exception' => $exception]));
   throw $exception;
}
```

It's a few more characters of course, but I would pick the readability
and simplicity over the potential typos (which the IDE should point
out) and a few key presses it saves.I

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

Re: [PHP-DEV] [PDO] I want to unify the behavior when changing the autocommit mode setting while a transaction is open.

[Ayesh Karunaratne]

>
> Hi,
>
> > In the latter case, I suppose they would expect the behaviour to be 
> > compliant with the database standards.
>
> I may not have had this perspective. And this is a strong basis for 
> explaining that different drivers behave differently.
>
> I will continue with the current implementation and consider the optimal 
> method for each driver.
>
>

I wanted to mention a recent RFC that passed its vote
(https://wiki.php.net/rfc/pdo_driver_specific_subclasses). It proposes
to add a PDO subclass for each driver, so we can make individual
driver-specific functions and changes more visible at the API level.

Unfortunately it did not make it to PHP 8.3, but the RFC vote
indicates the trajectory everyone hopes to have in PDO. It was voted
yes unanimously, so there is definitely a preference in majority of us
to iron out the differences, but perhaps in a non-BC way, preferably
making these inconsistencies obvious from the API level and not at the
test/doc levels.

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

Re: [PHP-DEV] [RFC] [Discussion] Resource to object conversion

[Ayesh Karunaratne]

> More importantly, it is possible to write cross compatible code, even
> without changing anything about is_resource(), if we convert streams to
> opaque objects.
> It might be tedious and one might need to have redundant instanceof checks
> with is_resource() if one does not want to check for a false return, or
> duplicate checks for closed resources.
>


Extensions like GD, IMAP, Curl, and FTP were once very "resource
heavy", but they already received this migration with next to none
disruptions. Shameless plug here
(https://php.watch/articles/resource-object) where I track the
progress. As these changes were merged in the last couple years, I
spent a few hours grepping the Composer top 1000 packages. There were
not that many `is_resource` checks, and it was quite easy and
straightforward to update them to account for the class objects.

I'm supportive of our trajectory so far by slowly but steadily moving
resource objects to class objects. I also support that we do not
modify `is_resource` to mark resource class objects as a resource. I
really look forward to the day that we remove `is_resource` and kill
the final resource object in PHP 梁.

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

Re: [PHP-DEV] Fix the inconsistent behavior of PDO::PARAM_XXX

[Ayesh Karunaratne]

>
> Hi internals,
>
> As shown in the following issue, the behavior of `PDO::PARAM_` is 
> inconsistent and I would like to fix this.
> https://github.com/php/php-src/issues/12603
>
> First, I tried fixed pdo_pgsql.
> https://github.com/php/php-src/pull/12605
>
> Eventually I plan to make similar changes to all bundled pdos.
>
> What do you think about these? If there is a reason for the current 
> implementation that should not be changed, it would be very helpful if you 
> could tell me why.
>
> Also, if an RFC is required, it would be helpful if you could point it out as 
> well. Personally, I don't think an RFC is necessary since this is some kind 
> of bug fix. However, I believe the target should be the master branch as it 
> changes the user experience somewhat.
>
> [*] I'm not thinking about LOB here, but once I leave them with their 
> existing behavior, I change the behavior of other types. Because LOB have 
> complex behavior, the scope becomes too large. After making this change, I 
> will test again and post another issue if necessary.
>
> [*] I would like the type of PARAM_BOOL to be exactly bool, but this would 
> also require changing the behavior of the emulator, and I would not be able 
> to issue a PR for each driver, making the scope too large. For this as well, 
> I will just align it to `int(1)` or `string(1) 't'`, etc., and once these 
> changes are completed, I will verify it and post an issue.
>
> [*] odbc etc. are not compatible with emulation in the first place. There are 
> no plans to change this in this context.
>
> Regards.
>
> Saki

I also commented on the PR, but in the interest of keeping the
conversation in the mailing list, I'll summarize my thoughts here as
well.

I don't think we should change the existing behavior. It may be an
xkcd/1172 case, but these kinds of cases are very hard to spot from
static analyzers, and are often only surfaced in production only if
someone spent enough time to dig deep. It's not helping when certain
database softwares try to be forgiving and sloppy with types (looking
at you, MySQL).

In the PR, I proposed to add new methods (`bindStringValue`,
`bingBoolValue`, etc) as a non-BC approach, that also rely on the
existing type system to communicate the types and enforce them. Saki
said that it might not be possible to introduce 10+ new methods to
`PDOStatement`, to which I also agree. However, maybe we can
conservatively add the basic four types (BOOL/NULL/INT/STR) as a
start.

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

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Ayesh Karunaratne]

>
> PHP lacks two very basic functions for working with arrays:
>
> - array_first() returning the first element of an array (or null)
> - array_last() returning the last element of the array (or null)
>
> While PHP has functions that return the first and last keys,
> array_key_first() and array_key_last(), it does not have more useful
> functions for values.
>
> a) What about reset() and end()?
> Programmers "abuse" the reset() and end() functions for this purpose.
> The problem is that these functions are used to move the internal
> pointer in the array. Which is why they have a name that is
> inappropriate when used in the sense of "return me the first element".
>
> Much worse, they shouldn't to be used to get first/last value, because
> they have a side effect (i.e. moving the pointer).
>
> Further, in the absence of an element, they return the obsolete false
> and not the currently expected null, which can be combined with the ??
> operator. In this they differ from the similar functions
> array_key_first() and array_key_last().
>
> b) What about $array[array_key_first($array)]?
>
> For such basic functions as returning the first and last item in an
> array, there should be a function in the basic package, not a
> workaround. Moreover, this requires having the array in a local
> variable, since $this->getFoo()[array_key_first($this->getFoo())]
> would be very inefficient and possibly incorrect.
>
> c) Two such functions were proposed and rejected during the
> array_key_first/last RFC
> (https://wiki.php.net/rfc/array_key_first_last)
>
> Yes, that was in 2018. At that time, functions like str_contains() or
> str_starts_with() wouldn't have even come into existence, just because
> there was an obscure way to do it without them. I believe we've moved
> on since then. Today we know how useful it is to use simple,
> easy-to-understand methods, both for programmers who write and read
> the code.
>
> DG
>

I would love to have these functions in PHP as well.

With the bikeshed risk, perhaps it makes more sense to have the
functions named `array_value_first` and `array_value_last`, because we
already have `array_key_first` and `array_key_last` functions?

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

Re: [PHP-DEV] Proposal to unbundle imap/pspell/oci8 extensions for PHP 8.4

[Ayesh Karunaratne]

> > ext/imap
> >
> > The library that provides the functionality in this extension, c-client,
> > is no longer updated. The last release from 2007 is no longer available
> > on the original distributor's (University of Washington) website, but
> > there is an unofficial GitHub repository that hasn't been updated for 5
> > years either (https://github.com/uw-imap/imap).
> >
> > You can't also use this any more with G Suite due to authentication
> > changes (https://github.com/uw-imap/imap/issues/4).
> >
> > There are several user-land packages that are still maintained, and
> > provide superior functionality:
> >
> > - https://github.com/PHPMailer/PHPMailer
> > - https://github.com/zetacomponents/Mail/
> > - https://github.com/symfony/mailer
> > - https://github.com/laminas/laminas-mail
> >
>
> Those alternatives are for sending e-mails. IMAP is for reading
> e-mails. They are not equivalent.
> Am I missing something here?
>

You are right that PHPMailer, laminas and Symfony Mailer are for
sending emails, but Zeta supports retrieving email over IMAP.

https://packagist.org/packages/webklex/php-imap is a popular and
active alternative as well.

Considering the lack of updates from upstream as Derick mentioned,
lack of OAuth support (which webklex/php-imap supports), and a
somewhat lackluster documentation for ext-imap in php.net, I think
unbundling ext-imap (along with the other extensions in the proposal)
makes sense.

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

Re: [PHP-DEV] RFC json_validate() - status: Under Discussion

[Ayesh Karunaratne]

> whether returning boolean is the right thing to do at all. It seems obviously
> intuitive it should, returning true for valid and false for invalid JSON
> but then if you consider you're still going to be in the situation of
> calling json_last_error() if you want to know why invalid JSON was invalid
> and in particular you might not expect the "last error" to have changed
> just from an attempt to check a string. How can there be an error when by
> definition you weren't trying to do anything except check the validity of
> some unknown data? Not sure what the answer is there...curious what other
> people's views are on that. I don't think throwing an exception on invalid
> JSON is the right answer in any case.

One of the reasons why I like `json_validate` over `is_json` is that
the former does not imply a boolean return value as strongly as the
latter.

I think we should not modify any state with the `json_validate`
function, and I'd be happy with the function returning 0 for a valid
JSON, or the error code as an integer (`JSON_ERROR_STATE_MISMATCH`,
`JSON_ERROR_SYNTAX`, etc.). `JSON_ERROR_NONE` constant is already
assigned 0, so they align quite well too.

As for exceptions, I too think throwing an exception here is an
anti-pattern. It makes perfect sense to throw on `json_decode` if the
program doesn't want to deal with invalid JSON gracefully. But calling
`json_validate` is an intended call, and returning an error is
excepted, and not an exception.

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

Re: [PHP-DEV] Removing Travis CI

[Ayesh Karunaratne]

Awesome, thanks a lot for this.

On Mon, Jul 11, 2022 at 1:50 AM Nikita Popov  wrote:
>
> On Sun, Jul 10, 2022 at 10:07 PM Ayesh Karunaratne  wrote:
>>
>> Dear Internals,
>> Historically, we have been using Travis CI for our automated tests,
>> but since 2021 June, travis-ci.org has ceased operations, and no
>> longer runs any builds. There was an Internals discussion
>> (https://externals.io/message/112709) to move to the successor,
>> travis-ci.com, but I don't think we ever moved there.
>>
>> Quoting Nikita from that thread:
>>
>> > We haven't been using Travis as our primary CI for a while already. We use
>> > AppVeyor for Windows testing and Azure Pipelines for everything else. The
>> > only thing Travis is still used for is a daily cron job that tests PHP on
>> > "exotic" architectures like aarch64 and s390x. Having those builds is a
>> > nice to have, but not particularly critical.
>>
>> As far as I see, Travis does not run php-src builds anymore; neither
>> on push, nor on cron.
>>
>> https://travis-ci.org/github/php/php-src leads to a page that says the
>> project was moved to travis-ci.com, and the linked page
>> (https://travis-ci.com/php/php-src) throws a 404. I think we have now
>> fully moved to GitHub Actions (thanks to amazing efforts by Ilija) +
>> Azure Pipelines + Appveyor + Circle CI, so perhaps it's time we remove
>> all the Travis-related code from php-src? I'd gladly volunteer for it,
>> if we reach a consensus to remove it.
>
>
> We use Travis CI to test architectures that are not available through other 
> CI providers, in particular aarch64 and s390x. Testing aarch64 is very 
> important, because we provide a JIT implementation for it. Testing s390x is 
> useful, because it is a big-endian architecture.
>
> The build page you are looking for is 
> https://app.travis-ci.com/github/php/php-src. Just like other CI runs, it is 
> linked from GitHub's commit CI interface, so I'm not sure why you got the 
> impression that it does not run builds.
>
> It's unfortunate that we need to use multiple CI providers, because a single 
> one does not offer all relevant architectures and operating systems (Cirrus 
> CI is used for their FreeBSD support).
>
> Regards,
> Nikita

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

[PHP-DEV] Removing Travis CI

[Ayesh Karunaratne]

Dear Internals,
Historically, we have been using Travis CI for our automated tests,
but since 2021 June, travis-ci.org has ceased operations, and no
longer runs any builds. There was an Internals discussion
(https://externals.io/message/112709) to move to the successor,
travis-ci.com, but I don't think we ever moved there.

Quoting Nikita from that thread:

> We haven't been using Travis as our primary CI for a while already. We use
> AppVeyor for Windows testing and Azure Pipelines for everything else. The
> only thing Travis is still used for is a daily cron job that tests PHP on
> "exotic" architectures like aarch64 and s390x. Having those builds is a
> nice to have, but not particularly critical.

As far as I see, Travis does not run php-src builds anymore; neither
on push, nor on cron.

https://travis-ci.org/github/php/php-src leads to a page that says the
project was moved to travis-ci.com, and the linked page
(https://travis-ci.com/php/php-src) throws a 404. I think we have now
fully moved to GitHub Actions (thanks to amazing efforts by Ilija) +
Azure Pipelines + Appveyor + Circle CI, so perhaps it's time we remove
all the Travis-related code from php-src? I'd gladly volunteer for it,
if we reach a consensus to remove it.

Thank you,
Ayesh.

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

Re: [PHP-DEV] Windows PECL build machine died

[Ayesh Karunaratne]

With php-src's recently starting to Github Actions, would it be
possible for PECL builds to use Github Actions with Windows. It
supports Windows server 2016, 2019, and even 2022 (IIRC).

On Fri, Apr 8, 2022 at 5:17 PM Christoph M. Becker  wrote:
>
> Hi all,
>
> bad news: the Windows PECL build machine died!  Is there anybody
> interested in sponsoring a successor?  That (virtual) machine would need
> to run 24/7, and to be configured to run php/web-rmtools, basically
> listening for new PECL releases, and to build them as soon as possible.
> It should run on Windows 10 Professional, or on some Windows Server 2019
> (or maybe Windows 11/Windows Server 2022); I don't think there are
> special requirements regarding the hardware.
>
> Anyhow, many thanks to Alex Schoenmaker who sponsored the old PECL build
> machine for many years!
>
> --
> Christoph M. Becker
>
> --
> 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] Pre-RFC: Redacting parameters in back traces (SensitiveParameter Attribute)

[Ayesh Karunaratne]

Hi Tim,
Thank you for opening the discussion. I personally find this feature
useful, and glancing at the diff, it looks like a rather
straightforward and minimal change.

FWIW, it is possible to selectively expose class properties in a class
object being `var_dump`-ed with the `__debugInfo` magic method, but it
is not used for stack traces.

For the RFC, someone with the permission to grant RFC karma should
grant it for you to start the RFC and open it for voting. You emailed
the right mailing list, I think someone will see this soon.
You can open a PR and start code reviews in the meantime.

Cheers,
Ayesh.

On Fri, Jan 7, 2022 at 11:40 PM Tim Düsterhus, WoltLab GmbH
 wrote:
>
> Hi Internals!
>
> PHP's stack traces in exceptions are very useful for debugging, because
> they include the original parameters for each stack frame, allowing the
> developer to see exactly what data is passed to a function call.
>
> Unfortunately sometimes this verbosity is a drawback. Specifically when
> sensitive values, such as credentials, are passed to a function and some
> other function deep down the call stack throws an Exception.
>
> One common "offender" is PDO which takes the database password as a
> constructor parameter and immediately attempts to connect to the
> database within the constructor, instead of having a pure constructor
> and a separate ->connect() method. Thus when the database connection
> fails the stack trace will include the database password:
>
> > PDOException: SQLSTATE[HY000] [2002] No such file or directory in 
> > /var/www/html/test.php:3
> > Stack trace:
> > #0 /var/www/html/test.php(3): PDO->__construct('mysql:host=loca...', 
> > 'root', 'password')
> > #1 {main}
> We're developing an application that is commonly self-hosted by
> laypersons at a shared hosting provider. This application includes an
> error log, logging any uncaught exception including its stack trace.
> Depending on the configuration by the customer it might also publicly
> print error details, because this eases debugging by the layperson
> administrator.
>
> To keep (database) credentials out of the log files - and more
> importantly hidden from any public visitors - our exception handler
> specifically scans the full stack trace for the PDO constructor to
> replace any parameters. More recently the exception handler was extended
> to also check each parameter via Reflection and redact any values for
> parameters called $password, $secret, and similar names. It also redacts
> any parameter having a `SensitiveArgument` attribute defined in our
> software.
>
> While this works reasonably well for any code we write, it does not work
> for non-stock exception handlers, e.g. loggers such as Sentry. It also
> cannot redact sensitive arguments in third party libraries that do not
> match one of the special-cased parameter names, because they won't have
> the SensitiveArgument attribute.
>
> For this reason we'd like to propose a *standardized* attribute to mark
> parameters as sensitive. This attribute can then be used by libraries to
> indicate their sensitive parameters.
>
> With regards to loggers our proposal would be that PHP itself performs
> the redaction when collecting the parameters for all stack frames.
> Specifically we propose that PHP will place an object of the
> SensitiveParameter class instead of the actual parameter value. This way
> an exception handler can easily detect which parameters have been
> redacted by performing an `instanceof SensitiveParameter` check.
>
> The `zend.exception_ignore_args` option is not an alternative in our
> opinion:
> - On shared webhosters, the customer might not be able to configure it.
> - The stack trace parameters are just too useful for debugging to
> completely strip them.
>
> The `zend.exception_string_param_max_len` option is not alternative either:
> - Many sensitive values might already be fully exposed before they are
> truncated. This specifically includes end-user credentials which tend to
> be low-entropy and shortish.
>
> We have created a proof of concept implementation of our proposal at:
>
> https://github.com/php/php-src/compare/master...WoltLab:sensitive-parameter
>
> For the RFC and the final implementation we would need assistance by
> someone who is more experienced in PHP internals and the RFC process.
>
> What our implementation already handles:
> - Redaction of ordered arguments.
> - Redaction of named arguments.
> - Redaction of variadic arguments.
>
> What's missing:
> - Adding arguments to native functions / methods / classes (e.g. PDO's
> constructor)
>
> Thank you all for reading through our proposal. We're happy to hear your
> feedback!
>
> I already registered a Wiki account (timwolla, duester...@woltlab.com)
> and would require RFC karma to proceed if you feel like the proposal is
> worthwhile writing up as an RFC.
>
> PS: It appears that the time on the ezmlm host is misconfigured. The
> email to confirm my subscription was dated 09:42:51 -, 

Re: [PHP-DEV] header() allows arbitrary status codes

[Ayesh Karunaratne]

>
> Hi all,
>
> a while ago it has been reported[1] that our header() function actually
> allows arbitrary status codes, which may even overflow.  Of course, that
> makes no sense, since the status code is supposed to be a three digit
> code.  So this ticket has been followed up by a pull request[2], and
> Jakub suggested to further restrict the status code to be in range 100 -
> 599.
>
> Since this could break some pathological cases, I wanted to ask whether
> anybody objects to this change for the master branch (i.e. PHP 8.2).
>
> [1] 
> [2] 

I think it is a useful improvement.  Should we adjust to
http_response_code to match this behavior?

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

Re: [PHP-DEV] PHP Foundation

[Ayesh Karunaratne]

Hi Nikita,
Thank you so much for what you have done for PHP, the language and the
community we all are in. I can't muster enough words to say how
grateful I am to you for all the changes we have in PHP all these
years. From every commit I see from you, to every podcast I listen to,
from every PR review, and all other interactions, you have absolutely
amazing and a gift. We all have been inspired and gifted by your
contributions to PHP, and the massive positive impact they made on all
of our lives.

I wish you all the best on your new path, and hope that we get to see
you often when the time permits.

Love,
All of us at PHP Community.


On Mon, Nov 22, 2021 at 10:53 PM Nikita Popov  wrote:
>
> Hi internals!
>
> I have two bits of news. The first is that I'm changing jobs at the end of
> the month, and won't be working on PHP in a professional capacity anymore.
> I'll still be around, but will have much less time to invest in PHP
> development. I'd like to thank JetBrains for sponsoring my work on PHP for
> the last three years -- I think we've managed to accomplish quite a lot.
>
> The second one is that the long-discussed idea of a PHP Foundation is
> finally becoming a reality! For the full details, please see the
> announcement: https://jb.gg/phpfoundation
>
> The initial purpose of the PHP Foundation is to support the development of
> PHP by contracting developers to work on php-src either part-time or
> full-time. If that sounds interesting to you, be sure to apply!
>
> The foundation does not have any decision-making power on language changes:
> these remain within the sole purview of the internals mailing list and the
> RFC process. The fact that some work has been funded by the foundation does
> not imply that it will be accepted into PHP.
>
> The setup of the foundation was admittedly a bit of a rush job, with the
> focus being on securing initial funding and making it available as soon as
> possible. For this reason the foundation only has a temporary
> administration that will need to figure out necessary bylaws for long-term
> operation.
>
> A big thanks goes to Roman Pronskiy from JetBrains for organizing this
> effort, as well our initial sponsors and everyone who provided early
> feedback.
>
> Regards,
> Nikita

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

Re: [PHP-DEV] Unbreak git.php.net links?

[Ayesh Karunaratne]

>
> S, what's next?
>
> On Tue, 5 Oct 2021 at 18:06, Hans Henrik Bergan 
> wrote:
>
> > @Ayesh thanks, added support for those url (
> > https://github.com/divinity76/git-php-net-redirector/commit/072a579d140a7481e76e95bd8c2d120ee2f71565
> > ), also it looks like version numbers got mixed up in your example #2 ,
> > "8.0.0RC2" vs "8.1.0RC3", that is surely a typo?
> >
> > >It is the name of the git repository on git.php.net. There were
> > several other repos for PECL, bug tracker, docs in multiple languages,
> > etc. I have added support for a static list that maps git.php.net
> > names to GitHub repo under `php` organization namespace.
> >
> > oh i see.
> >
> > fwiw, your implementation looks more professional / enterprise-y :)
> >
> >
> > On Tue, 5 Oct 2021 at 15:43, Ayesh Karunaratne  wrote:
> >
> >> > here is an initial implementation:
> >> >
> >> https://github.com/divinity76/git-php-net-redirector/blob/main/src/redirector.php
> >> > it is just a minimum-effort implementation, anyone feel free to make
> >> > something better (also i have no idea how the "p" argument is supposed
> >> to
> >> > be parsed, so i just guessed)
> >> >
> >> > it passes "Stanislav Malyshev"'s initial sample url, but it probably
> >> fails
> >> > on any other formats, if anyone has test urls, share em
> >> >
> >> >
> >> >
> >> > On Mon, 4 Oct 2021 at 08:38, Hans Henrik Bergan 
> >> > wrote:
> >> >
> >> > > >So who's going to work on it? Doesn't make sense to have 5 people
> >> work
> >> > > > on it independently from each other ;-)
> >> > >
> >> > > if nobody else wants to do it, i can make an initial implementation on
> >> > > october 9th (6 days from now),
> >> > >
> >> > > but wouldn't surprise me at all if someone else wants to do it ^^
> >> > >
> >> > >
> >> > > On Mon, 4 Oct 2021 at 08:01, Andreas Heigl  wrote:
> >> > >
> >> > >> Hey all.
> >> > >>
> >> > >> On 04.10.21 07:52, Hans Henrik Bergan wrote:
> >> > >> > there's also plenty of broken links on reddit to git.php.net , ref
> >> > >> > https://www.google.com/search?q=git.php.net+site%3Areddit.com
> >> > >> >
> >> > >> > it wouldn't be hard to set up a redirector parsing commit ids out
> >> of the
> >> > >> > url and redirecting to github,
> >> > >> > +1 from me.
> >> > >>
> >> > >> So who's going to work on it? Doesn't make sense to have 5 people
> >> work
> >> > >> on it independently from each other ;-)
> >> > >>
> >> > >> Cheers
> >> > >>
> >> > >> Andreas
> >> > >> --
> >> > >>,,,
> >> > >>   (o o)
> >> > >>
> >> +-ooO-(_)-Ooo-+
> >> > >> | Andreas Heigl
> >>  |
> >> > >> | mailto:andr...@heigl.org  N 50°22'59.5" E
> >> 08°23'58" |
> >> > >> | https://andreas.heigl.org
> >>|
> >> > >>
> >> +-+
> >> > >> | https://hei.gl/appointmentwithandreas
> >>|
> >> > >>
> >> +-+
> >> > >>
> >> > >
> >>
> >>
> >> Hi Stanislav/Hans,
> >> Thanks for opening this conversation and the initial implementation.
> >>
> >> Having worked with a few cgit repositories before, I happen to recall
> >> some of the other URL patterns. I worked on a similar implementation
> >> to Hans's at https://github.com/Ayesh/git-php-redirect
> >>
> >> > something better (also i have no idea how the "p" argument is supposed
> >> to
> >> > be parsed, so i just guessed)
> >>
> >> It is the name of the git repository on git.php.net. There were
> >> several other repos for PECL, bug tr

Re: [PHP-DEV] Unbreak git.php.net links?

[Ayesh Karunaratne]

> here is an initial implementation:
> https://github.com/divinity76/git-php-net-redirector/blob/main/src/redirector.php
> it is just a minimum-effort implementation, anyone feel free to make
> something better (also i have no idea how the "p" argument is supposed to
> be parsed, so i just guessed)
>
> it passes "Stanislav Malyshev"'s initial sample url, but it probably fails
> on any other formats, if anyone has test urls, share em
>
>
>
> On Mon, 4 Oct 2021 at 08:38, Hans Henrik Bergan 
> wrote:
>
> > >So who's going to work on it? Doesn't make sense to have 5 people work
> > > on it independently from each other ;-)
> >
> > if nobody else wants to do it, i can make an initial implementation on
> > october 9th (6 days from now),
> >
> > but wouldn't surprise me at all if someone else wants to do it ^^
> >
> >
> > On Mon, 4 Oct 2021 at 08:01, Andreas Heigl  wrote:
> >
> >> Hey all.
> >>
> >> On 04.10.21 07:52, Hans Henrik Bergan wrote:
> >> > there's also plenty of broken links on reddit to git.php.net , ref
> >> > https://www.google.com/search?q=git.php.net+site%3Areddit.com
> >> >
> >> > it wouldn't be hard to set up a redirector parsing commit ids out of the
> >> > url and redirecting to github,
> >> > +1 from me.
> >>
> >> So who's going to work on it? Doesn't make sense to have 5 people work
> >> on it independently from each other ;-)
> >>
> >> Cheers
> >>
> >> Andreas
> >> --
> >>,,,
> >>   (o o)
> >> +-ooO-(_)-Ooo-+
> >> | Andreas Heigl   |
> >> | mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
> >> | https://andreas.heigl.org   |
> >> +-+
> >> | https://hei.gl/appointmentwithandreas   |
> >> +-+
> >>
> >


Hi Stanislav/Hans,
Thanks for opening this conversation and the initial implementation.

Having worked with a few cgit repositories before, I happen to recall
some of the other URL patterns. I worked on a similar implementation
to Hans's at https://github.com/Ayesh/git-php-redirect

> something better (also i have no idea how the "p" argument is supposed to
> be parsed, so i just guessed)

It is the name of the git repository on git.php.net. There were
several other repos for PECL, bug tracker, docs in multiple languages,
etc. I have added support for a static list that maps git.php.net
names to GitHub repo under `php` organization namespace.

In addition to the URL patterns Hans have covered
(p=php-src;h=HEX{40}), I thought to add a few more patterns:

- FROM: http://git.php.net/?p=php-src.git;a=commit;h=5af586be (
`/[a-z0-9]{7,}$/` )
  TO:   https://github.com/php/php-src/commit/5af586be

- FROM: https://git.php.net/?p=php-src.git;a=shortlog;h=refs/tags/php-8.0.0RC2
  TO:   https://github.com/php/php-src/releases/tag/php-8.1.0RC3

- FROM: 
https://git.php.net/?p=php-src.git;a={tree,log,shortlog};h=refs/heads/master;hb=refs/heads/master
  TO:   https://github.com/php/php-src/{tree,commits,commits}/master

- FROM: http://git.php.net/?p=php-src.git;a=log
  TO:   https://github.com/php/php-src

Cheers,
Ayesh.

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

Re: [PHP-DEV] [RFC] Deprecate dynamic properties

[Ayesh Karunaratne]

>
> Hi internals,
>
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
> https://wiki.php.net/rfc/deprecate_dynamic_properties
>
> This has been discussed in various forms in the past, e.g. in
> https://wiki.php.net/rfc/locked-classes as a class modifier and
> https://wiki.php.net/rfc/namespace_scoped_declares /
> https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/-language-evolution.md
> as a declare directive.
>
> This RFC takes the more direct route of deprecating this functionality
> entirely. I expect that this will have relatively little impact on modern
> code (e.g. in Symfony I could fix the vast majority of deprecation warnings
> with a three-line diff), but may have a big impact on legacy code that
> doesn't declare properties at all.
>
> Regards,
> Nikita

Hi Nikita,
Thanks for opening this, I'm very supportive of this.

Having some Drupal and other legacy background, I'm afraid this could
disrupt a lot of Drupal applications, which uses dynamic properties
quite extensively in its Entity APIs, Views, etc. I totally agree that
it is a bad practice, but that's what half a million or so Drupal 7
web sites do.

Perhaps, we can make it an easy to opt-in with a keyword (`locked
class Foo {}`) or an interface (`Foo implements LockedClass {}`), or
provide an easy opt-out (similar to the tentative return type
attribute)?

Thank you,
Ayesh.

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

Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str

[Ayesh Karunaratne]

> I agree about the _string suffix removal. However, I know we have
> parse_url() already, but parse_query() might be too generic. I would
> suggest adding "http" to the name. And as we already have
> http_build_query() I would rather see http_parse_query().
>

+1 for http_parse_query() as it sounds a lot more natural and consistent.

> parse_str assumes that the query separator is always a "&" which reduces
> its usage to only parsing query using that particular character. Again this
> might be seen as an edge case but no RFC prevents using any other
> character. If you where to use another character you are bound to use some
> userland code workaround to then feed the "normalized" string to parse_str

Both `http_build_query` and `parse_str` respect the
`arg_separator.input` [INI
setting](https://www.php.net/manual/en/ini.core.php#ini.arg-separator.input).
If we were to go for a `http_parse_query`, I think it makes sense to
support the same behavior and parameters.

Thank you,
Ayesh.

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

Re: [PHP-DEV] RFC: autoconst

[Ayesh Karunaratne]

>
> Hello!
>
> This is my first RFC proposal. I have an idea about introducing autoconst 
> keyword.
> Motivation:
> reduce duplicated code (copy/pasting constant name as value)
> reducing potential typo errors in constant values
>
> instead of defining constants like:
> const FOO = 'FOO';
>
> they could be defined like:
> autoconst FOO; // defines a constant FOO with the value 'FOO'
>
> Also, modifiers could be useful:
> autoconst uppercase foo; // defines a constant foo with value 'FOO'
> autoconst lowercase FOO; // defines a constant FOO with value 'foo';
>
> and maybe:
> autoconst camelcase FOO_BAR; // defines a constant FOO_BAR with value 'fooBar'
> autoconst snakecase fooBar; // defines a constant fooBar with value 'foo_bar'
>
> could be listed like:
> autoconst FOO, BAR, BAZ;
> autoconst lowercase FOO, BAR, BAZ;
>
> What do you think about that? If you like my idea, I would request a karma 
> for creating this RFC in the wiki. Hope you'll like the idea!

Hi Serhii,
With Enums supported in PHP 8.1, I think this pattern of using
constant names with identical values will see fewer use cases.
I also don't think that a proposal to add new common keywords like
`uppercase` / `snakecase`, or adding any magic to constant names
(because PHP 7 supported case-insensitive constants) will be received
well either.

Thanks,
Ayesh.

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

Re: [PHP-DEV] Proposal: clamp

[Ayesh Karunaratne]

> Greetings internals,
>
> I present to you a proposal for a new basic math function: clamp.
>
> The main goal of this function is to contain a number inside a given bound.
> And return the number if it is inside of that bound, and if not, and the
> number is outside of the given bound, the nearest bound is returned.
>
> Now, does this need an RFC? The behaviour can be implemented in userland
> in a number of ways, one of which is to compare the values in a if statement.
> Another is to use the min and max math functions.
>
> max($min, min($max, $num));
>
> I don’t have any schpeel as to why this should be in core, only that I 
> thought it already was.
> Considering it is part of other languages standard math library, and it is a 
> useful function.
>
> Can see this being useful in image manipulation, server-side rendering and 
> math just to name few.
>
> The proposed signature follows the convention of other math related functions.
>
> function clamp(int|float $num, int|float $min, int|float $max): int|float {}
>
> This function is very easy to implement, has no side effects or backward
> compatibility issues, unless a userland implementation already has the 
> function declared,
> in which case PHP will throw a fatal error since the function cannot be 
> redeclared.
>
> I've implemented this feature a few months ago already.
> - Link: https://github.com/thinkverse/php-src/pull/1 
> 
>
> What are your opinions on this function?
>
> Regards,
> Kim Hallberg.


 +1 from me as well.

We recently added `str_contains`/`starts_with`/`ends_with`, which were
welcome additions. I think `clamp` would be a nice addition too.

I found three user-land `clamp` function declarations on a search on
GitHub public repos.

 - 
[doubleleft/hook](https://github.com/doubleleft/hook/blob/master/src/bootstrap/helpers.php#L129)
- 764 stars, Last activity in 2016.
 - 
[GetSimpleCMS/GetSimpleCMS](https://github.com/GetSimpleCMS/GetSimpleCMS/blob/master/admin/inc/basic.php#L2489)
- 336 stars, Has recent activity.
 - 
[shish/shimmie2](https://github.com/shish/shimmie2/blob/master/core/polyfills.php#L477)
- 267 stars, Has recent activity.

I think it's safe to say that these libraries will be updated to
accommodate the `clamp` function in PHP core; I'd even happily send
pull requests to them. `doubleleft/hook` probably wouldn't be updated
because it doesn't show recent activity, but that's an acceptable BC
impact for a nice addition IMO.

Thank you,

---
Ayesh.

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

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Ayesh Karunaratne]

>
> Den søn. 6. jun. 2021 kl. 00.09 skrev Ayesh Karunaratne :
> >
> > Hi Ben,
> > Thank you for opening this PR and the discussion. With the wide
> > availability of AVIF/AV1 support in browsers, I think this will fit
> > nicely.
> >
> > We have the Namespaces in Bundled Extensions RFC
> > (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so
> > perhaps, the new functions are probably better in the `Gd` namespace?
> > This would mean the new functions would be `\Gd\imagecreatefromavif`
> > and `\Gd\imageavif`. They are inconsistent with the existing functions
> > of course, but I thought to mention it because it's a recent proposal
> > and I don't think we added new functions after that RFC. Some examples
> > are recently renamed PHP classes in IMAP, Pgsql, LDAP, and FTP
> > extensions to follow this new proposal.
>
> I don't think it makes much sense to do that for a single function,
> because it makes the API cluttered, as why would I call
> `\Gd\imagecreatefromavif` when everything else is in the global
> namespace? That is a poor design, while I understand the intentions
> behind it is good.
>
> I think this needs to be well thoughtout in a topic on its own rather
> than off topicing it here, so I will leave it at that.
>
>
> Overall, +1 for adding this
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net

I also think going with `imagecreatefromavif`/`imageavif` is good for
consistency. I brought that RFC up because it was recent and this is
the first new function we are adding.

Thank you.

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

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Ayesh Karunaratne]

Hi Ben,
Thank you for opening this PR and the discussion. With the wide
availability of AVIF/AV1 support in browsers, I think this will fit
nicely.

We have the Namespaces in Bundled Extensions RFC
(https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so
perhaps, the new functions are probably better in the `Gd` namespace?
This would mean the new functions would be `\Gd\imagecreatefromavif`
and `\Gd\imageavif`. They are inconsistent with the existing functions
of course, but I thought to mention it because it's a recent proposal
and I don't think we added new functions after that RFC. Some examples
are recently renamed PHP classes in IMAP, Pgsql, LDAP, and FTP
extensions to follow this new proposal.

---
Thank you.

Ayesh.

On Fri, Jun 4, 2021 at 8:06 PM Ben Morss via internals
 wrote:
>
> Hello, everyone!
>
> Earlier this year, I added support for AVIF images
>  to libgd
> . My ultimate goal was to bring support for
> this new image format to PHP, so that the world's top CMSs could let sites
> serve AVIFs. Recently, @Christoph M. Becker  and Nikita
> have kindly been guiding me as I created a PR to propagate libgd's AVIF
> support into PHP's bundled gd fork. This would create two new PHP functions
> for systems with gd enabled: imagecreatefromavif() and imageavif().
> Additionally it would add AVIF awareness to imagetypes().
>
> This PR  now looks ready to go.
> Christoph advised me to write to this list to ask folks to take a look, and
> to see if there are any objections to merging it!
>
> If the group approves the first PR, my plan is to finish another PR
>  to add AVIF support to the
> non-gd image function getimagesize() . In the same PR, I plan to add
> support to PHP's internal _php_image_type() function, which is used in
> imagecreatefromstring().
>
> Thanks for your help with all of this!
>
>
> All best,
>
> Ben Morss

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

Re: [PHP-DEV] json_encode indent parameter

[Ayesh Karunaratne]

Hi Timon,
Thank you for this RFC. I think the `string|int $indent` approach is great !

Reading the PR, it looks like `$indent=0` is essentially turning off
pretty-print, which I think is intuitive.

Do you plan to add any sort of validation on negative integers?
Perhaps throw a `\ValueError` exception on $indent < 0?

---
Thank you.
Ayesh.

On Thu, Jun 3, 2021 at 9:19 PM Timon de Groot  wrote:
>
> On 3-6-2021 16:15, G. P. B. wrote:
> > That's incorrect, as of PHP 8.0 Fast ZPP has a way to deal with the most
> > common union types, including int|string.
> >
> > Best regards,
> >
> > George P. Banyard
>
> I found that STR_OR_LONG works fine, thanks for acknowledging!
>
> --
>
> Kind regards,
>
> Timon de Groot
>
> --
> 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] [RFC] Deprecate ticks

[Ayesh Karunaratne]

>
> Hi Nikita,
>
> wt., 11 maj 2021 o 10:53 Nikita Popov  napisał(a):
>
> > Hi internals,
> >
> > I'd like to propose the depreciation of the ticks mechanism:
> > https://wiki.php.net/rfc/deprecate_ticks
> >
> > I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> > is a language change, even if not a particularly important one...
> >
>
> Glad to see this topic. That's a YES
>
> Cheers,
> Michał Marcin Brzuchalski

I agree too.

I can't think of use cases with ticks, other than signal handling or
profiling code. We already have better tooling for both of them.

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

Re: [PHP-DEV] add php.ini entry to set default user_agent for curl

[Ayesh Karunaratne]

Hi Michael,
Thanks for opening this conversation and the PR.

Most HTTP client libraries that need to set a custom user agent do so
with `curl_setopt` because it needs to contain a library version or
some sort of dynamic values. They will likely not benefit from this
change. On the other hand, libraries that do not bother to set a UA
string probably wanted it that way too, because Curl's default UA
string is useful as it contains the Curl version.

That said, if it comes to it that we add this feature, I'd be in favor
of a new `curl.user_agent` as opposed to inheriting the global
`user_agent` because that would be BC break. We already have
`curl.cainfo` INI setting, and adding a new `curl.user_agent` wouldn't
be a drastic change to configuration either.

-- Ayesh.



>
> Dear Internals,
> I'd like to suggest a new enhancement for 8.1 as outlined in the title.
>
> The initial pull request is here:
> https://github.com/php/php-src/pull/6834/files
>
> --- Details:
> Since quite a while PHP offers a dedicated user_agent php.ini entry, but it
> affects only all internal implementations like file_get_contents. cURL has
> no default and you need to modify CURLOPT_USERAGENT in the code and for the
> SoapClient there is a parameter 'user-agent' in the constructor which can
> be set.
>
> Therefore I'd like to introduce an equal entry for curl.user_agent which
> would set a default user_agent when making curl requests. Of course you can
> override it with CURLOPT_USERAGENT if required. (I can implement the same
> for SoapClient, if requested)
>
> --- Alternative:
> I could also use the default user_agent entry, but I wasn't sure what the
> best practise is and went for the more "local" approach for the initial
> implementation.
>
> --- Bigger picture:
> When the preferred solution is to use the default user_agent, we could also
> try to determine more places where i could send the default user_agent to
> give this php.ini entry a more consistent feeling.
>
> Thanks for your consideration,
> Michael
>
> PS: Subscribing to the list through https://www.php.net/mailing-lists.php is
> not possible and quits with the following error: We were unable to
> subscribe you due to some technical problems. Please try again later.

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

Re: [PHP-DEV] Changes to Git commit workflow

[Ayesh Karunaratne]

I think this is a great step forward.
With commit signatures required, I think the person who merges a PR
now needs to do so locally. [GitHub CLI](https://cli.github.com/)
helps me a lot to locally checkout a PR quickly, and then
rebase/squash with my own signature.

Thanks to Levi Morrison and Nikita for the very quick response.

>
> On Mon, 29 Mar 2021, 03:30 Rasmus Lerdorf,  wrote:
>
> > On Sun, Mar 28, 2021 at 17:15 Sara Golemon  wrote:
> >
> > > On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella 
> > > wrote:
> > >
> > >> You might consider requiring commits be signed while you're at it.
> > >>
> > >>
> > > I suggested this as well, and even if we don't require it, we should
> > > STRONGLY encourage it.
> > >
> > > I've been signing my commits for several years now, it's not even that
> > > hard.
> > >
> > I think for php-src commits we can require it. For doc and other repos we
> > can make it optional for now until people are more comfortable with it.
> >
> > -Rasmus
>
>
> >
> > We can require Signed Commits for the main active branches on GitHub:
> > https://docs.github.com/en/github/administering-a-repository/about-protected-branches#require-signed-commits
>
>
> We can create rules that requires that for all active maintained version of
> PHP.
>
> We can set that per repo, or in a organization level.
>
> - Gabriel Caruso

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

Re: [PHP-DEV] include vendor/autoload.php automatically

[Ayesh Karunaratne]

Larry already mentioned `auto_append_file` that I also think is the
way to go, if it fits.

The example directory structure from your email is also considered
insecure, because without proper web-server protection, you are
essentially exposing _all_ `vendor` files, including the ones that
potentially execute code.

On Sat, Mar 27, 2021 at 10:23 PM Abdul Haq Sheikh
 wrote:
>
> If we want to use composer packages, we have to include
> 'vendor/autoload.php', and if we don't have a front controller design
> pattern, we must include 'vendor/autoload.php' on every/most files. Why not
> to auto include 'vendor/autoload.php' file (if vendor folder exists)?
> * PHP will use include_once to include file
>
> Example Directory Structure:
> - Index.php (file)
> - Test.php (file)
> - Classes  (folder)
> -- Classes/test2.php (file)
> - Vendor (folder)
>
> - On Index.php, php will automatically include  'vendor/autoload.php'
> because the vendor directory exists.
> - On Test.php, php will automatically include  'vendor/autoload.php'
> because the vendor directory exists.
> - On Classes/test2.php, since file is in sub directory and here vendor
> directory doesn't exist, so php will not include 'vendor/autoload.php'

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

Re: [PHP-DEV] What should we do with utf8_encode and utf8_decode?

[Ayesh Karunaratne]

Thank you for opening this conversation, these functions have stung me
in the past, and I would be so happy to see them gone :)

Personally, I would very much like to go with Plan A.

- XML parsers that often deal with non-UTF-8 character encodings
frequently use these functions. However, any parser worth their salt
is better off using mbstring or iconv because of the lack of
Windows-1252 support that is assumed elsewhere for ISO-8859. If we
have a `utf8_encode` that supports Windows-1252 as often expected, I
think plan B would be the more smoother upgrade.

 - On Packagist top 1000 downloads, stripe-php, phpcpd, pdepend,
carbon, monolog, php-cs-fixer, htmlpurifier, and aws-php-sdk use
`utf8_encode`. Some of these libraries depend on `ext-mbstring` or
Symfony mbstring polyfill, so we are left with even fewer libraries
that cannot assume `iconv()` or `mb_convert_encoding` availability.

On Sun, Mar 21, 2021 at 7:48 PM Rowan Tommins  wrote:
>
> Hi all,
>
> The functions utf8_encode and utf8_decode are historical oddities, which
> almost certainly would not be accepted if proposed today:
>
> * Their names do not describe their functionality, which is to convert
> to/from one specific single-byte encoding. This leads to a common
> confusion that they can be used to "fix" UTF-8 encoding problems, which
> they generally make worse.
> * That single-byte encoding is ISO 8859-1, not its common cousins
> Windows-1252 or ISO 88159-15. This means, for instance, that they do not
> handle the Euro sign: utf8_decode('€') returns '?' (i.e. unmappable)
> not "\x80" (Windows-1252) or "\xA4" (8859-15)
>
> On the other hand, they are commonly used, both correctly and
> incorrectly, so removing them is not easy.
>
> A previous proposal to remove them [1] resulted in Andrea making two
> significant improvements: moving them from ext/xml to ext/standard [2]
> and rewriting the documentation to explain them properly [3]. My genuine
> thanks for that.
>
> However, it hasn't stopped people misunderstanding them, and quite
> reasonably: you shouldn't need to look up every function you use in the
> manual, to make sure it actually does what its name suggests.
>
>
> I can see three ways forward:
>
> A) Raise a deprecation notice in 8.1, and remove in 9.0. Do not provide
> a specific replacement, but recommend people look at iconv() or
> mb_convert_encoding(). There is precedent for this, such as
> convert_cyr_string(), but it may frustrate those who are using the
> functions correctly.
>
> B) Introduce new names, such as utf8_to_iso_8859_1 and
> iso_8859_1_to_utf8; immediately make those the primary names in the
> manual, with utf8_encode / utf8_decode as aliases. Raise deprecation
> notices for the old names, either immediately or in some future release.
> This gives a smoother upgrade path, but commits us to having these
> functions as outliers in our standard library.
>
> C) Leave them alone forever. Treat it as the user's fault if they mess
> things up by misunderstanding them.
>
>
> I am happy to put together an RFC for either A or B, if it has a chance
> of reaching consensus. I would really like to avoid option C.
>
>
> [1] https://externals.io/message/95166
> [2] https://github.com/php/php-src/pull/2160
> [3]
> https://github.com/php/doc-en/commit/838941f6cce51f3beda16012eb497b26295a8238
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> 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] [RFC] Autoloader Classmap

[Ayesh Karunaratne]

Please ignore my last message :(

Hi Internals,
I did a somewhat rough test to compare Composer's autoloader and the
function proposed in the RFC.

## TL;DR:

autoload_set_classmap over Composer with OPCache: 8.12%
autoload_set_classmap over Composer without OPCache: 7.93%


## Long version:

Using symfony/framework-bundle , symfony/console, and phpunit/phpunit,
in a new composer project, I created a classmap (`composer
dump-autoload -ao`) in `vendor/composer/autoload_classmap.php`, file.
To keep the test fair, I removed the Composer autoload.files (always
include those files), and platform-check to keep the test fair. I had
to comment out the "Error during autoloading from classmap. Entry
\"%s\" failed to load the class from \"%s\" (Class undefined after
file included)" exception because it errored for valid classes. Using
Composer 2.

Benchmark called `class_exists()` on the Composer-generated classmap,
with autoloading enabled. On the same tests, it called 10K
`class_exists('test\\test_' . $i)` where $i = 1...10K. Results are
averaged from 3 runs.

**Composer autoloader**
With OPCache: 20.337 sec.
Without OPCache: 20.042 sec.

**autoload_set_classmap**
With OPCache: 18.684 sec
Without OPCache: 18.451 sec

**Performance gain**
autoload_set_classmap over Composer with OPCache: 8.12%
autoload_set_classmap over Composer without OPCache: 7.93%

I think 7-8% difference is more of a best-case scenario for
autoload_set_classmap, because the default unauthoritative classmap
has PSR-4/0/files/classmap features, and some sanity checks to avoid
collisions. I don't think a reasonable PHP application will have
2K autoload hits and 10K misses. This is indeed an improvement, and
something I would use myself if approved. However, I doubt real-life
applications would see any noticeable difference in other measures
such as response time or req/sec count.

Smile,
Ayesh.

On Fri, Mar 19, 2021 at 8:16 PM Nikita Popov  wrote:
>
> On Mon, Mar 15, 2021 at 6:41 PM Mark Randall  wrote:
>
> > Hi Internals,
> >
> > I would like to propose the addition of a new mechanism of autoloading
> > classes - a classmap that will be consulted prior to checking the
> > spl_autoload_register'd callbacks.
> >
> > https://wiki.php.net/rfc/autoload_classmap
>
>
> Could you please update the RFC with some performance numbers, including
> the used methodology? The number of 5% has been floating around, but it's
> not clear what it refers to. I'm primarily interested in end-to-end effect,
> e.g. on the symfony demo project.
>
> Regards,
> Nikita

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