Re: [PHP-DEV] PDO subclass names

[Calvin Buckley]

On Apr 30, 2024, at 8:07 AM, Arvids Godjuks  wrote:
> On Tue, 30 Apr 2024 at 12:07, Matteo Beccati  wrote:
> Hi,
> 
> 
> > If MariaDB wants to maintain a specific PDO Driver they can do so 
> > themselves and publish it on PECL, same as how CUBRID (and others) does 
> > currently.
> 
> That is true, however it's mysqlnd the part that deals with the network 
> protocol, which they wouldn't be able to modify from PECL. That said, 
> I'm not an expert on mysql/maria, but I also doubt the changes are 
> significant enough that they need a separate driver.
> 
>  I wasn't proposing rolling a separate driver or anything like that, just an 
> alias that would reserve a namespace for MariaDB and if there's ever a need 
> to actually roll the driver, that alias be replaced with actual driver.
> The thing is at this point MySQL and MariaDB have a different set of 
> additional capabilities that are not compatible between the two. Doctrine, at 
> this point, actually makes a distinction between MariaDB and MySQL - those 
> are considered different databases.
> This would allow people to use MariaDB and MySQL-specific functionality by 
> using the respective driver namespace and remove any confusion about if this 
> works with both or only one of them.
> 
> I know it seems to be out of scope, but this deals with PDO subclass names 
> and this seems to be a thing to consider here. Sure, we can have a separate 
> RFC about it, but I think this is the right moment to handle this question.
> 

Has the network protocol diverged much? I know storage engines, query language, 
etc. might change, but the underlying protocol might be similar.

Re: [PHP-DEV] [RFC][Discussion] PDO driver specific parsers

[Calvin Buckley]

On Apr 17, 2024, at 9:24 AM, Matteo Beccati  wrote:
> 
> Hello everybody,
> 
> I'd like to start a discussion on a new RFC about fixing the default PDO SQL 
> parser and having (optional) driver-specific parsers.
> 
> https://wiki.php.net/rfc/pdo_driver_specific_parsers
> 
> Thanks GPB and Tom de Wit for their help with initial proof-reading.
> 
> 
> Cheers
> -- 
> Matteo Beccati
> 
> Development & Consulting - http://www.beccati.com/

FWIW, ODBC would annoyingly complicate things by not exposing a single
dialect, but it handles placeholders directly, so it hasn't needed to
parse queries. Using standard SQL quoting would probably work for most
drivers though if it comes to it.

Re: [PHP-DEV] Requiring GPG Commit Signing

[Calvin Buckley]

On Apr 2, 2024, at 11:15 AM, Derick Rethans  wrote:
> 
> 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).

Would this affect only direct pushes to master, or would it be required
for pull requests too? I'd be worried the average drive-by contributor
wouldn't have GPG signing set up.

Re: [PHP-DEV] Release Managers for PHP 8.4

[Calvin Buckley]

On Mar 5, 2024, at 11:37 AM, Jakub Zelenka  wrote:
> 
> Please put your name forward here if you wish to be considered a candidate. 
> An initial TODO page has been added to the wiki and contains provisional 
> dates for GA and pre-releases [2].
> 

I'm putting my hat in to the ring again for 8.4 release manager.

As for qualifications, I think I'm somewhat familiar with internals, as
I maintain a PHP distribution for the IBM i platform as well as various
database extensions (Db2 extensions in PECL, and now ODBC in ext/). I
have done some triage of PHP changes, at least in regards to platform
compatibility. The work of a release manager seems like a logical
extension of that.

~cb

[PHP-DEV] Re: Testing new list server

[Calvin Buckley]

On Feb 14, 2024, at 11:16 AM, Derick Rethans  wrote:
> 
> Please don't be alarmed, we're moving the lists over to a new machine.

I've been getting a ton of spam from php-general@ recently.
I suspect the changeover might be related.

Re: [PHP-DEV] Proposal: Binary type for PDO

[Calvin Buckley]

> On Jul 9, 2023, at 11:29 AM, Dan Ackroyd  wrote:
> 
> On Fri, 7 Jul 2023 at 18:39, Calvin Buckley  wrote:
>> 
>> I'd like to hear any oversights, and what could be done to take this
>> further.
> 
> I think someone needs to write some code and some tests, and see what happens.
> 
> It's possible that PARAM_BINARY could be used across all of the PDO
> drivers that PHP ships with, and for each of them the behaviour with
> that option is sensible.
> 
> It's also possible that the behaviour of binary parameters is bespoke
> to each of the drivers, and that it isn't possible to use PARAM_BINARY
> in a DB agnostic way.
> 
> The most realistic way to find out which option is more real, is to
> write the code + testswhich would need to be done anyway, even
> assuming the best case scenario.

I have a WIP PR here:

https://github.com/php/php-src/pull/11674

I have not implemented MySQL/Postgres/OCI/Firebird support, but I have
tests for ODBC, DBLIB, and SQLite. I think your suspicions about it
being bespoke might be correct, although the exercise isn’t for naught.
Even if a PARAM_BINARY isn’t realistic to implement, it still identifies
and has some fixes for PDO_ODBC and PDO_DBLIB that could be used
independently from any PARAM_BINARY support. Further review and me
figuring out the other drivers could help here.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Proposal: Binary type for PDO

[Calvin Buckley]

Hi internals@,

I’m linking to a GH issue I filed a file back about extending PDO. It's
intending to address common issues with dealing with bindary data that
I've seen users deal with.

In particular, I’d appreciate feedback from people with PDO internals,
and any other DBMS' features/limitations that could affect this.

The issue on GitHub is here:

https://github.com/php/php-src/issues/11462

I'd like to hear any oversights, and what could be done to take this
further. I haven’t heard much other than some +1s on the issue itself.

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

Re: [PHP-DEV] Proposal: native decimal scalar type support

[Calvin Buckley]

You’re going to likely have this with database as well - at least ODBC presents 
decimals as strings, because they can’t be represented as a C type (without 
turning it into a struct of some sort).

> On Apr 26, 2023, at 9:23 AM, Alexander Pravdin  wrote:
> 
> On Wed, 26 Apr 2023 at 20:52, Benjamin Morel  wrote:
> 
>> For what it’s worth, this is already solved in userland:
>> https://github.com/brick/math
> 
> When I checked the sources, the first I saw was:
> 
>> final class BigInteger extends BigNumber
>> {
>> private string $value;
> 
> It also converts to strings back and forth which can not be as
> performant as native calculations and still is (with respect to the
> authors) yet another band-aid over the missing core functionality. I
> know that there are workarounds, but my proposal is about native
> support.
> 
> --
> 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] [VOTE] PHP 8.3 Release Managers

[Calvin Buckley]

On Apr 17, 2023, at 6:01 PM, Sergey Panteleev  wrote:
> 
> Hi all,
> 
> The polls have closed, and Derick’s scripts have tallied the votes [1],
> 
> Our “rookie" PHP 8.3 release managers are:
> - Jakub Zelenka
> - Eric Mann
> 
> Our "veteran” is the PHP 8.2 release manager Pierrick Charron.
> Jakub and Eric you are in a good hands!
> 
> Further steps are described in the New release manager checklist [2],
> I believe you can discuss it with Pierrick.
> 
> Calvin, I hope you’ll consider putting in your name for future release 
> manager elections.
> 
> Thank you to all!
> 
> [1] https://gist.github.com/derickr/9dca6c23663eb44b58d380ae8b914e5a
> [2] 
> https://github.com/php/php-src/blob/b340e10d6e32df0ca586e06d0c9406402b47205f/docs/release-process.md#new-release-manager-checklist
> 
> Cheers,
> Sergey


Of course :)

Best of luck to everyone with PHP 8.3!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Release Managers for PHP 8.3

[Calvin Buckley]

On Wed, 2023-03-01 at 23:20 +0300, Sergey Panteleev wrote:
> Please put your name forward here if you wish to be considered a
> candidate. An initial TODO page has been added to the wiki and
> contains provisional dates for GA and pre-releases [2].

I'll throw my hat into the ring, since I had previously applied for the
PHP 8.2 release manager position.

I have familiarity with internals and a bit of the release process due
to packaging PHP as a downstream (supporting the IBM i platform) and
maintaining PECL extensions (ibm_db2/PDO_IBM). There's a lot of triage
of user issues (understanding them, providing solutions/patches, etc.),
so I feel I could assess PRs on the other side of review. I've also
thrown a lot of fixes back upstream, in particular with the ODBC
extensions. Currently I just worked on some patches to improve error
reporting with sessions/HTTP responses.

As such, I think my background would make me a good candidate.

~cb

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

Re: [PHP-DEV] Re: [8.2] Release Manager Election

[Calvin Buckley]

On Wed, 2022-05-18 at 13:45 -0500, Ben Ramsey wrote:
> 
> Our 8.2 “rookie” release managers are:
> 
> * Sergey Panteleev
> * Pierrick Charron
> 
> Congratulations!
> 
> Thank you to all the candidates! I hope you’ll consider putting in
> your name for future release manager elections, and as always, PHP
> needs your help in many other ways, so please continue to volunteer
> and help out.
> 
> Sergey and Pierrick, I’ll be in touch with you soon to get you
> started on the first alpha release of 8.2, due out on 9 June.

Congratulations to them! I'm glad that 8.2 will be in good hands.

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

Re: [PHP-DEV] PHP 8.2 Release Manager Selection

[Calvin Buckley]

On Mon, 2022-04-25 at 13:51 +0200, Christoph M. Becker wrote:
> 
> Please put your name forward here if you wish to be considered a
> candidate.  An initial TODO page has been added to the wiki and
> contains
> provisional dates for GA and pre-releases[2].
> 

I'll put my name in the hat for applying to be an RM. I actually
package PHP as a downstream (for IBM i users), have tried to do what I
can for triaging issues (usually on behalf of my clients), and have
written some PRs for upstream. The skills there should be able to
inform the process as an RM, if I become one. I see some other good
candidates though, so I think 8.2 will be in good hands regardless.

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

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

[Calvin Buckley]

This might be interesting. I've set up Actions builds for extensions,
and the Windows part was pretty easy (thanks to Christoph's action for
setting up a PHP build environment on Windows). If I could set up a
workflow that when I tag a release, it pushes a full matrix to PECL,
that would be great.

On Fri, 2022-04-08 at 17:25 +0530, Ayesh Karunaratne wrote:
> 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).

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

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Calvin Buckley]

On Sep 22, 2021, at 11:24 AM, Matthew Weier O'Phinney 
 wrote:
> As somebody who's been contributing to and maintaining OSS libraries
> forever (since 2002), the pace of change of PHP is, frankly, ridiculous. I
> can keep up with patches. I can keep up with new features. But BC breaks
> EVERY YEAR just creates churn. I've spent most of the past 18 months doing
> nothing but ensuring libraries work on new PHP versions. I then get users
> angry that they aren't getting new features; if I don't update to the
> latest PHP version, I get other users angry they can't use the library on
> the newer PHP version. And with new PHP versions every year... I
> essentially have to update every 2-3 years regardless, and will lose users
> if I don't do it every year.
> 
> Figure out what the BC breaks are going to be, and do them all at once.
> It's far easier for the ecosystem to adapt to a big drop of BC breaks every
> 3-5 years than it is every year.

There’s merit to spacing it out - I doubt anyone wants another PHP 7 flag day 
again.

(Ask the Python people how they feel about moving all the breaking changes to a 
single release…)

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

Re: [PHP-DEV] BC breaking changes in PHP 8.1

[Calvin Buckley]

I suspect this is true (I have not tested yet to be sure) for the Toolkit for 
IBM i, since it looks at resource types for the same purpose (determine 
database connection type). Minor fix, but it is a BC break.

> On Sep 22, 2021, at 10:29 AM, Matthew Weier O'Phinney 
>  wrote:
> 
> Yesterday, I opened an issue regarding a change in the pgsql extension (
> https://bugs.php.net/bug.php?id=81464).
> 
> PHP 8.0 introduced the concept of "resource objects". Where previously we
> would have resources, and use `get_resource_type()` when we needed to
> differentiate various resources, resource objects give us immutable objects
> instead that allow us to type hint. Personally, I think this is wonderful!
> 
> The rollout for 8.0 was incomplete, however, and only touched on something
> like 4-6 different resource types. Still, a good start.
> 
> With PHP 8.1, we're seeing the addition of more of these, and it was
> encountering one of those changes that prompted the bug I previously linked
> to.
> 
> Here's the issue: while overall, I like the move to resource objects,
> introducing them in a MINOR release is hugely problematic.
> 
> Previously, you would do constructs such as the following:
> 
>if (! is_resource($resource) || get_resource_type($resource) !==
> $someSpecificType) {
>// skip a test or raise an exception
>}
> 
> Resource objects, however:
> 
> - Return `false` for `is_resource()` checks.
> - Raise a warning for `get_resource_type()` checks, and/or report the
> resource object class name — which differs from the previous resource names
> in all cases.
> 
> This means conditionals like the above BREAK. As a concrete example, I did
> PHP 8.1 updates for laminas-db last week, and assumed our postgres
> integration tests were running when we finally had all tests passing
> successfully. However, what was really happening was that our test suite
> was testing with `is_resource()` and skipping tests if resources were not
> present. We shipped with broken pgsql support as a result, and it wasn't
> until test suites in other components started failing that we were able to
> identify the issue.
> 
> Further, the "fix" so that the code would work on both 8.1 AND versions
> prior to 8.1 meant complicating the conditional, adding a `! $resource
> instanceof \PgSql\Connection` into the mix. The code gets unwieldy very
> quickly, and having to do this to support a new minor version was
> irritating.
> 
> When I opened the aforementioned bug report, it was immediately closed as
> "not an issue" with the explanation that it was "documented in UPGRADING".
> 
> This is not an acceptable explanation.
> 
> - There was no RFC related to 8.1 indicating these changes were happening.
> (In fact, there was no RFC for resource objects in the first place — which
> is concerning considering the BC implications!)
> - In semantic versioning, existing APIs MUST NOT change in a new minor
> version, only in new major versions.
> 
> Reading the UPGRADING guide, there's a HUGE section of backwards
> incompatible changes for 8.1 — THIRTY-FOUR of them. Nested in these are
> notes of around a half-dozen extensions that once produced resources now
> producing resource objects.
> 
> The pace of change in PHP is already breathtaking when you consider large
> projects (both OSS and in userland); keeping up with new features is in and
> of itself quite a challenge. Introducing BC breaks in minor versions makes
> things harder for everyone, as now you have to figure out not only if
> there's new features you want to adopt, but whether or not there are
> changes that will actively break your existing code. I strongly feel that
> anything in the backwards incompatible section of the UPGRADING guide
> should be deferred to 9.0, when people actually expect things to change.
> 
> -- 
> Matthew Weier O'Phinney
> mweierophin...@gmail.com
> https://mwop.net/
> he/him

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

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

[Calvin Buckley]

Good point, but I'm still on GCC 10 in Fedora. I haven't tried its
static analyzer yet either. That said, I don't know how GCC's analyzer
handles PHP's ewhateveralloc functions - that is, if it'd do better
than LLVM.

On Tue, 2021-05-25 at 23:43 +0100, G. P. B. wrote:
> Isn't this handled by the GCC 11?

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

Re: [PHP-DEV] Using clang-analyzer with PHP: experiences?

[Calvin Buckley]

I did some additional research and seemed to have decent luck with slamming a 
construct like this after the includes:

#define emalloc  malloc
#define erealloc realloc
#define ecalloc  calloc
#define estrdup  strdup
#define estrndup strndup
#define efreefree

One could wrap it around `__clang_analyzer__` or such. Unfortunately, this is 
kinda ugly; it emits compiler warnings, but I suspect this probably belongs in 
PHP itself or perhaps in some kind of clang-analyzer addon that handles the e* 
allocation functions as well as things like mismatching them.

> On May 21, 2021, at 4:01 PM, Calvin Buckley  wrote:
> 
> Hi internals@,
> 
> I maintain an extension and I suspect there are some issues in the code. As 
> such, I’ve been trying various tools to try to make it easier to catch the 
> issues. (For the curious: I’ve tried *San, which I feel doesn’t work very 
> well unless you /totally control/ the entire stack, which I didn’t have the 
> luxury of. I also tried Valgrind, but I need ro revisit this to deal with 
> possible false positives in the library.) This time, I decided to try static 
> analysis through LLVM.
> 
> Luckily, clang-analyzer is pretty simple. Just prepending “scan-build” to my 
> make invocation. Easy, right? Unfortunately, I noticed that due to an 
> inconsistency in the codebase (a use of realloc instead of erealloc), that it 
> doesn’t seem to account for i.e emalloc vs. malloc. Possible leaks “went 
> away” from the output when I converted them to the PHP memory management 
> functions.
> 
> Has anyone ever used clang-analyzer with PHP before? I noticed there was some 
> tooling for a previous PHP transition [1], but I don’t know if anyone’s 
> tackled the low-hanging fruit of memory functions. I suppose I could just 
> redefine emalloc and friends, but I feel that would probably be inaccurate 
> with things like zend_string.
> 
> Regards,
> Calvin
> 
> [1]: https://github.com/johannes/clang-php-checker
> --
> 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] Using clang-analyzer with PHP: experiences?

[Calvin Buckley]

> On May 21, 2021, at 4:48 PM, Levi Morrison  
> wrote:
> 
> Just to check: are you setting the environment variable USE_ZEND_ALLOC
> to 0? This causes the engine to use malloc:
> https://heap.space/xref/PHP-7.4/Zend/zend_alloc.c?r=600402d9#2738.
> 
> For what it's worth, I was recently annoyed _again_ by valgrind being
> so noisy because zend_string_equal_val intentionally reads past the
> end of a zend_string. The allocator ensures that memory was allocated,
> but it isn't guaranteed to be initialized. We should find some way to
> initialize this memory for future releases -- maybe add a function
> which null terminates a zend string by adding not 1 null byte but as
> many as necessary to reach the end of the allocation. This should be
> trivial enough in cost to do, compared to some other solutions like
> always zero'ing out the whole memory block or initializing the
> trailing bytes at zend_string_alloc time.
> 
> Also, I'm not sure this read-past-the-end technique is actually safe,
> such as when USE_ZEND_ALLOC is set to zero and we use malloc directly,
> which does not make the same guarantees about alignment and padding on
> the string...
> 
> Nikita pushed up this change only today, but it would theoretically
> help with valgrind being used a runtime but not compiled with valgrind
> support: 
> https://github.com/php/php-src/commit/a0c44fbaf19841164c7984a6c21b364d391f3750.
> I say theoretically only because I haven't tested it yet.

WRT Valgrind: Yes, I do run it with that environment variable, because 
run-tests sets it for you when using Valgrind. Unfortunately there’s some more 
false positives, but it’s coming from the library the extension is wrapping. 
I’d need to take some time to figure out if that’s a false positive, a leak 
caused by me, or worse, a leak in the library itself. The additional 
improvements to Valgrind support are welcome though.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Using clang-analyzer with PHP: experiences?

[Calvin Buckley]

Hi internals@,

I maintain an extension and I suspect there are some issues in the code. As 
such, I’ve been trying various tools to try to make it easier to catch the 
issues. (For the curious: I’ve tried *San, which I feel doesn’t work very well 
unless you /totally control/ the entire stack, which I didn’t have the luxury 
of. I also tried Valgrind, but I need ro revisit this to deal with possible 
false positives in the library.) This time, I decided to try static analysis 
through LLVM.

Luckily, clang-analyzer is pretty simple. Just prepending “scan-build” to my 
make invocation. Easy, right? Unfortunately, I noticed that due to an 
inconsistency in the codebase (a use of realloc instead of erealloc), that it 
doesn’t seem to account for i.e emalloc vs. malloc. Possible leaks “went away” 
from the output when I converted them to the PHP memory management functions.

Has anyone ever used clang-analyzer with PHP before? I noticed there was some 
tooling for a previous PHP transition [1], but I don’t know if anyone’s tackled 
the low-hanging fruit of memory functions. I suppose I could just redefine 
emalloc and friends, but I feel that would probably be inaccurate with things 
like zend_string.

Regards,
Calvin

[1]: https://github.com/johannes/clang-php-checker
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Calvin Buckley]

I'm just going to say...

- almost all modern mail clients are threaded, it's trivial to view
context, so I want to see replies "above the fold"
- bottom posting goes against the grain of modern mail clients
- overall, it just feels like arbitrary preferences set decades ago;
worst case it feels like hazing against people who don't use mutt/pine

I personally top-post (as it's the default for all the mail clients I
use) when replying unless it's a point-by-point reply, in which case I
reply inline. I'm not bothered by bottom posting nor do I make a fuss
when I see other conventions, but it's more inconvenient to read.

(I also have to set my client to plain text manually per message -
that's another can of worms...)

On Mon, 2021-05-10 at 22:51 +0100, Kamil Tekiela wrote:
> Hi Internals,
> 
> Could we drop the bottom-posting rule?
> 
> Almost all new contributors fall into this trap and reply to a thread
> by
> top-posting, only to get chastised by someone else on the list. It's
> really
> difficult to remember to delete the default reply. Mail clients don't
> make
> it easy for us; it's hidden by default. Bottom-posting makes reading
> the
> thread much more difficult too. The actual reply gets lost in between
> the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and
> don't
> handle bottom-posting well. People are usually used to it and they
> read
> from top to bottom. I don't know if in the past some mail clients
> defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
> 
> If you want to quote someone then it makes sense to copy a part of
> the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous
> message
> on top of your own reply isn't very productive. It wastes time and
> screen
> space.
> 
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide
> the
> previous conversation? If not, then I think we can let people top-
> post.
> 
> Regards,
> Kamil

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

[PHP-DEV] Improvements to PDO_ODBC

[Calvin Buckley]

Hello internals@,

I've been looking into improving PDO_ODBC; specifically, bringing it up
to parity with other drivers, as well as dealing with its quirks. The
company I work for supports PHP on IBM i, and while we maintain the
native database drivers for the platform, we (and IBM) have been
recommending new applications migrate to ODBC.

However, the procedural ODBC driver does have some limitations like no
in/out parameters (which is a very common thing with stored procedures
here, unfortunately). PDO_ODBC does support this, but we've noticed
some issues:

 * Persistent connections aren't checked, even though the procedural
   ODBC driver does. This has bitten some of our clients, so we have a
   patch for them that does impement this; this is PR GH-6805.
 * Many of the connection attributes don't seem to be implemented; some
   of these seem trivial to implement, others less so.
 * In/out parameters require users to remember to specify size and add
   one for the null terminator. I'm not familar with other ODBC drivers
   to call this a driver/platform quirk, PDO_ODBC limitation, or
   something else, but figuring out a good solution for this would make
   life easier for users.
 * As always, ODBC being a generic abstraction later itself bites us
   (i.e no standard way to get last ID).

I'm curious if anyone has suggestions for what to be done or how to get
these done.

Regards,
Calvin
 * 

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

Re: [PHP-DEV] RFC: PHP JIT/arm64 port

[Calvin Buckley]

This is great work! I assume you've only tested much on Linux, but I do
have an M1 Mac here to test.

I'm curious how much effort this took you, in terms of figuring out the
CPU-specific parts of the JIT, and what needed untangling from machine-
specific code and what didn't. I've been curious what it'd take to
write another JIT backend (for a supported CPU in DynASM). I noticed
the changes you've made to generic parts of the JIT were minimal; only
improvements that'd be optional to dasm, minor detanglement in generic
code/the build system, and adding Capstone. The current state of the
JIT being x86 only made it hard to determine what was specific to x86
and what wasn't. The ARM backend here also seems pretty small compared
to the x86 one, though that might just be lack of feature parity.

(Regardless, better JIT docs would be great!)

On Wed, 2021-03-17 at 03:27 +, Hao Sun wrote:
> Hi Internals,
> 
> Currently PHP JIT only supports x86 and x86_64 CPUs on POSIX
> platforms and Windows.[1] With the prevalence of PHP language and the
> notable
> growth of ARM-based servers market, we believe JIT/arm64 would be in
> urgent need in the near future.
> 
> As an initial effort to enable PHP JIT/arm64, we (ARM) have supported
> the basic functionality, and (partially) implemented the compilation
> for
> several opcodes. Currently a number of simple JIT test cases from PHP
> test framework can be passed on ARM-based machine. There are still a
> lot
> of missing parts, such as hot loops, class/object/array operations,
> exception handling, etc, and we will continue working on them.
> 
> We would like to share our work with you (See the draft patch
> https://github.com/shqking/php-src/commit/6aaf935).
> Any feedback would be greatly appreciated, and please let we know if
> anyone wants to contribute to this port.
> 
> Thanks,
> Hao SUN
> Email: hao@arm.com
> 
> ---
> Main updates:
> 1. JIT backend for AArch64
> A new alternative, i.e. AArch64, was added while building PHP JIT.
> See the updates in the following files. Note that we adopt
> capstone[2] for
> disassembly on AArch64.
> 
>   build/Makefile.global
>   ext/opcache/config.m4
>   ext/opcache/config.w32
>   ext/opcache/jit/Makefile.frag
>   ext/opcache/jit/zend_jit.c
>   ext/opcache/jit/zend_jit_vm_helpers.c
>   ext/opcache/jit/zend_jit_disasm_arm64.c
>   ext/opcache/jit/zend_jit_gdb.c
>   ext/opcache/jit/zend_jit_perf_dump.c
> 
> 2. DynASM library
> PHP JIT uses DynASM[3] (developed for LuaJIT project) to generate
> native code on the fly. We added two useful but missing features,
> global label
> reference and dynamic register names, into DynASM/arm64. See the
> updates in files:
> 
>   ext/opcache/jit/dynasm/dasm_arm64.h
>   ext/opcache/jit/dynasm/dasm_arm64.lua
> 
> Note that these two features are available on DynASM/x86.
> 
> 3. compilation for opcodes on AArch64
> Our main work falls in the following files.
> 
>   ext/opcache/jit/zend_jit_arm64.h
>   ext/opcache/jit/zend_jit_arm64.dasc
>   ext/opcache/jit/zend_jit_internal.h
>   Zend/zend_vm_opcodes.h
> 
> * AArch64 registers and calling conventions are defined.
> 
> * Instruction cache must be flushed for the JIT-ed code on AArch64.
> See macro JIT_CACHE_FLUSH in file 'zend_jit_internal.h'.
> 
> * We have (partially) implemented the compilation for several
> opcodes, mainly for the function-based JIT (with opcache.jit=1203).
> Currently,
> test cases involving internal function call (e.g. var_dump),
> additions with integers/floating-point numbers, integer overflows and
> simple
> exception, can be supported now. See our newly added test cases under
> directory 'ext/opcache/tests/jit/arm64/'.
> 
> * Trace counter stubs are implemented for tracing JIT (with
> opcache.jit=1255). See zend_jit_hybrid_trace_counter_stub() and
> zend_jit_hybrid_hot_trace_stub() in file 'zend_jit_arm64.dasc'. Hot
> functions can be recognized and compiled successfully. See the test
> case 'hot_func_002.phpt'.
> 
> How to build and test:
> Our local test environment is an ARM-based server with Ubuntu 20.04
> and GCC-10. We follow the building commands as shown in the readme
> file [4].
> Note that library capstone should be installed in advance.
> 
> We suggest running the JIT test cases using the following command. In
> our local test, 59 out of all 128 cases can be passed currently.
>   $ make test TESTS='-d opcache.jit=1203 ext/opcache/tests/jit/'
> 
> [1] https://wiki.php.net/rfc/jit
> [2] https://www.capstone-engine.org/
> [3] https://luajit.org/dynasm.html
> [4] https://github.com/php/php-src
> 

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