Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions
> I like this concept, but instead of introducing a new syntax, have you
> considered leveraging attributes in the same way that PHP 8.3
> introduced #[Override]?
>
> #[Nonvariadic]
> function foo () {}
> foo(42); // warning: foo() expects exactly 0 arguments, 1 given
>
> I think the intent would be clearer and it would avoid introducing a new
> syntax.
>
I agree that using an attribute would be better for this case.
> I would personally prefer the void syntax, but that's really because
> attributes look odd to me due to lack of habits (and also because it avoids
> an additional line of code… which is probably not a solid enough reason when
> it comes to language design decisions).
As a reader of the code, having the attribute is much more clear to me
than having something that looks like an argument.
Also, with attributes, the code is backwards-compatible, i.e., I can
add the attribute to my code without any errors or warnings even if I
don't use the latest version of PHP, and even in those cases, IDEs
could still help me.
Re: [PHP-DEV] FFI in PHAR files
> If you choose not to use a phar, but instead, just loose PHP files, it > extracts the sources to a random `/tmp` directory when executing. So, > FFI and other things should "just work" without any shenanigans. > > Robert Landers > Software Engineer > Utrecht NL Thank you for the suggestion. The micro.sfx SAPI doesn't support adding multiple files, afaik, so what you mean is concating micro.sfx to my "entrypoint" and providing the whole source instead of just an executable? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] FFI in PHAR files
> > I suppose it'd be possible to improve FFI to call the PHP VFS layer to > > resolve a path, which would handle the phar:// scheme and other schemes. > > But, I would be worried about potential other downstream impacts - esp. > > security implications - as this is a novel (to me at least) scenario. I just realized I never explained the reason for me to wanna use this feature. My bad. I have a CLI project that uses FFI and it would be awesome if I could share it using the micro sfx API[1]. If FFI was supported inside PHARs, we could even create Desktop applications using tools such as php-tkui[2] and make them available via the aforementioned SAPI. Anyway, I just wanted to explain the motive behind my original question. :-D [1]: https://github.com/crazywhalecc/static-php-cli/blob/main/README.md#use-micro [2]: https://github.com/skoro/php-tkui -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PHP test coverage
> The code coverage report can be found at > https://app.codecov.io/github/php/php-src Ah, perfect. Thank you for sharing. I will take a closer look after work, but something seems weird to me. Here[1] you see that ctype_alpha seems to be uncovered, but here[2] we can see that it's tested. [1]: https://app.codecov.io/github/php/php-src/blob/master/ext%2Fctype%2Fctype.c#L112 [2]: https://github.com/php/php-src/blob/master/ext/ctype/tests/ctype_alpha_basic.phpt > I will have a look, the page overall looks like it could need some love ;-) > In the meantime if you are interested in writing tests, I once wrote a blog > post about that topic at > https://dev.to/realflowcontrol/growing-the-php-core-one-test-at-a-time-4g4k Ah, that's great. Thank you for that! :-D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] PHP test coverage
PHP doc article about writing tests [1] mentions gcov.php.net as the source to see the coverage, but this address is not available anymore. I believe this should be updated to show how the coverage can be found so people know where to focus their efforts if they want to contribute with tests. [1]: https://wiki.php.net/doc/articles/writing-tests -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Short Function Syntax
I honestly don't see any benefits. `function` isn't verbose, it's explicit. I prefer `function` over `fn` for methods. But despite what one may prefer, I believe changing the language syntax just because of "taste" probably isn't worth the effort. -- 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
> 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? Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional Em qua., 13 de set. de 2023 às 05:50, Derick Rethans escreveu: > > Hi, > > In a recent chat between the PHP Foundation developers, we discussed > unbundling several extensions. > > > 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 > > > ext/pspell > > The original underlying library hasn't been updated since 2001 > (https://en.wikipedia.org/wiki/Pspell) and it's replacement, aspell not > since 2019 (https://ftp.gnu.org/gnu/aspell/). > > There are other replacements, ispell, and hunspell, but they don't seem > to be compatible API-wise. The PECL extension "enchant" was supposed > to be able to use with all of these, but is also no longer maintained > (last release in 2009, https://pecl.php.net/package/enchant). > > Again, there are several user land composer packages > (https://packagist.org/?query=spell) that can be used instead. > > > ext/oci8 > > Requires a proprietary library from large commercial enterprise > (https://www.oracle.com/database/technologies/instant-client.html) and > has many outstanding bugs: > https://bugs.php.net/search.php?cmd=display&package_name[]=PDO+OCI&package_name[]=OCI8+related&package_name[]=Oracle+related&order_by=ts1&direction=ASC&limit=30&status=Open&reorder_by=ts1 > https://github.com/php/php-src/labels/Extension%3A%20oci8 > > Most of the recent changes were all to skip tests. > > It is also one of the larger extensions left that had not had their > resource type converted to objects. This is a major effort, and frankly, > probably something that should be done by the corporate sponsor of the > oracle extensions. > > > Please remember, that unbundling extensions does not mean that they > disappear. They will be moved to PECL with a release made. > > An RFC will of course be forthcoming, but we thought it best to email > the list first. > > > cheers, > Derick > > -- > https://derickrethans.nl | https://xdebug.org | https://dram.io > > Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support > Host of PHP Internals News: https://phpinternals.news > > mastodon: @derickr@phpc.social @xdebug@phpc.social > twitter: @derickr and @xdebug > > -- > 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] FFI in PHAR files
Ah, that makes total sense. I was worried I was doing something very wrong. haha Thank you very much for the detailed clarification. This doesn't seem to be a "critical" feature, but I wonder if the documentation shouldn't mention something about only "regular files" being supported. Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional Em sex., 8 de set. de 2023 às 16:55, Bishop Bettini escreveu: > > On Fri, Sep 8, 2023 at 2:33 PM Vinicius Dias wrote: >> >> I was playing around with some libraries using FFI and I wanted to >> share a .phar with the result, but to my surprise, it didn't work. >> >> Apparently we are not able to load shared libraries using FFI from >> within .phar files. >> Is that the expected behavior or is it a bug in the FFI extension? >> >> I have setup a dummy repo so the error could be easily reproduced: >> https://github.com/CViniciusSDias/ffi-phar-problem >> >> I am sorry if this is not the list to send this type of problem. I >> will gladly move the thread to the right one if someone points it out. >> https://www.php.net/unsub.php > > > Erstwhile PHAR extension maintainer here. What an interesting question! The > short answer is no, FFI does not support loading dynamic libraries contained > within a PHAR archive. > > The longer answer is that FFI was not written to be able to support VFS > locations, including the phar:// scheme. In this case, PHP starts and invokes > the code. The code invokes FFI[1] with a phar:// path, which then tries to > perform a dlopen()[2], which fails because dlopen has no idea how to resolve > PHAR paths: dlopen() expects a path that the OS can resolve[3]. > > I suppose it'd be possible to improve FFI to call the PHP VFS layer to > resolve a path, which would handle the phar:// scheme and other schemes. But, > I would be worried about potential other downstream impacts - esp. security > implications - as this is a novel (to me at least) scenario. > > bishop > > [1]:https://github.com/php/php-src/blob/50ca24251d97dbf78b0c1165dac7c1a19ff1c87a/ext/ffi/ffi.c#L2968C3-L2968C3 > [2]:https://github.com/php/php-src/blob/50ca24251d97dbf78b0c1165dac7c1a19ff1c87a/Zend/zend_portability.h#L156 > [3]:https://man7.org/linux/man-pages/man3/dlopen.3.html > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] FFI in PHAR files
I was playing around with some libraries using FFI and I wanted to share a .phar with the result, but to my surprise, it didn't work. Apparently we are not able to load shared libraries using FFI from within .phar files. Is that the expected behavior or is it a bug in the FFI extension? I have setup a dummy repo so the error could be easily reproduced: https://github.com/CViniciusSDias/ffi-phar-problem I am sorry if this is not the list to send this type of problem. I will gladly move the thread to the right one if someone points it out. Thanks, folks. Vinicius Dias, Zend Certified Engineer, iMasters PHP Certified Professional -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] PASSWORD_DEFAULT value
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
[PHP-DEV] PASSWORD_DEFAULT value
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
[PHP-DEV] session_regenerate_id concurrency problems
Hello, internals. I hope you all are well. The documentation page for the `session_regenerate_id`[1] function has the following warning: > **Warning** Currently, session_regenerate_id does not handle an unstable network well, e.g. Mobile and WiFi network. Therefore, you may experience a lost session by calling session_regenerate_id. You should not destroy old session data immediately, but should use destroy time-stamp and control access to old session ID. Otherwise, concurrent access to page may result in inconsistent state, or you may have lost session, or it may cause client(browser) side race condition and may create many session ID needlessly. Immediate session data deletion disables session hijack attack detection and prevention also. Since the documentation states that this problem exists **currently**, are there any plans to address it? Thank you all in advance. [1]: https://www.php.net/session_regenerate_id
[PHP-DEV] session_regenerate_id concurrency problems
Hello, internals. I hope you all are well. The documentation page for the `session_regenerate_id`[1] function has the following warning: > **Warning** Currently, session_regenerate_id does not handle an unstable network well, e.g. Mobile and WiFi network. Therefore, you may experience a lost session by calling session_regenerate_id. You should not destroy old session data immediately, but should use destroy time-stamp and control access to old session ID. Otherwise, concurrent access to page may result in inconsistent state, or you may have lost session, or it may cause client(browser) side race condition and may create many session ID needlessly. Immediate session data deletion disables session hijack attack detection and prevention also. Since the documentation states that this problem exists **currently**, are there any plans to address it? Thank you all in advance. [1]: https://www.php.net/session_regenerate_id -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Possible RFC: PDOStatement::addBatch
> Hi Vinicius,
>
> What would be the reason to add this? A reason cannot just be that there is
> no such function. You can easily do it with a loop like you have just shown.
> There isn't really any other way > unless we introduce some driver specific
> SQL builder. So what would we gain from it? Is it speed, security, efficiency?
>
> String concatenation isn't an alternative though.
>
> Regards,
> Kamil
Great question, Kamil. This new method would not add new capabilities to PHP.
It would make things easier for a batch insert. Currently, we would
need something like the following. This is a real world production
code, not written by me. I just decreased the number of columns and
changed table/column names:
```
prepare(
"INSERT INTO `table_name`(
`column_1`,
`column_2`
) VALUES
{$values}"
);
$counter = 0;
foreach ($data_list as $data) {
$statement->bindValue(++$counter, $data['specific_key'], PDO::PARAM_INT);
$statement->bindValue(++$counter, $data['another_key'], PDO::PARAM_INT);
}
$statement->execute();
$statement = null;
```
So when I said about string concatenation, that's what I meant. With
the new method, we would have something like:
```
prepare("INSERT INTO `table_name`(`column_1`,
`column_2`) VALUES (?, ?)");
foreach ($data_list as $data) {
$statement->bindValue(1, $data['specific_key'], PDO::PARAM_INT);
$statement->bindValue(2, $data['another_key'], PDO::PARAM_INT);
$statemnt->addBatch();
}
$statement->execute();
$statement = null;
```
But the biggest pro isn't this case. It's the case where beginners
would have multiple individual INSERT queries being separately sent to
the database because they are not familiar with the approach of
concatenating the parameters to the query string. I hope I made it a
bit more clear now, so to sum it up: this new method would not bring
any new functionality to PHP, but it would:
1. Make the code a bit more clear;
2. Help newcomers to write bulk INSERTs.
> I have a library that abstracts this for you, if that helps:
> https://github.com/brick/db
> - Benjamin
That `BulkInserter` class would basically be the point of this new
addition to the core, Benjamin. But a lot of new developers are not
even familiar with composer, so adding an external library is out of
their reality. Having an `addBatch` method in PHP's core would
definitely help them write a better and more performatic code.
I once again appreciate the attention and the replies.
Vinicius Dias.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Possible RFC: PDOStatement::addBatch
Hello, folks. I hope you all are well.
I was talking to friend about a feature I would like to see in PHP but
I mentioned that unfortunately I do not have the knowledge to try
implementing it myself, since it is not something very simple, so he
mentioned that I could bring this discussion up to this list and see
if there would be a person willing to develop that.
The feature is a new method in PDOStatement called addBatch to allow
batch INSERTs, exactly like Java's JDBC[1] has. This method would
allow us having one single INSERT SQL query, adding multiple values to
it, and sending this to the database at once, as one single query.
The idea would be something like this:
```php
prepare('INSERT INTO table (column) VALUES (?);');
foreach ($dataRows as $row) {
$statement->bindValue(1, $row, \PDO::PARAM_STR);
$statement->addBatch();
}
$statement->execute(); // or ->executeBatch if that's easier
```
Currently, to achieve the same goal, we need to perform string
interpolation (or concatenation) to assemble the batch INSERT query
and bind every value at once.
I have worked on a lot of projects where developers would perform
multiple different INSERT queries and if this method existed, it would
be a simple change to optimize those pieces of code.
As I mentioned, I don't have the knowledge to create the PR myself,
but I would be more than happy to help as I can. That includes writing
the RFC if it gets to that point (fingers crossed).
I am looking forward to hearing back your comments on this.
Thank you very much,
Vinicius Dias.
[1]:
https://docs.oracle.com/en/java/javase/20/docs/api/java.sql/java/sql/Statement.html#addBatch(java.lang.String)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
