Skip to content

Some cleanup in OCI8 extension for PHP 8 #5603

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 2 commits into from

Conversation

Girgias
Copy link
Member

@Girgias Girgias commented May 20, 2020

While working on #5526 I saw there was some version handling which stems from the PECL version.

Except if I'm mistaken, this shouldn't be needed any more as it lies within php-src

@Girgias Girgias mentioned this pull request May 20, 2020
87 tasks
@KalleZ
Copy link
Member

KalleZ commented May 20, 2020

This is probably a no-go because of how Oracle manages the extension, they support a wide range of unsupported PHP versions and the extension is dual released with PECL.

Maybe @cjbj can comment further on this.

@Girgias
Copy link
Member Author

Girgias commented May 20, 2020

This is probably a no-go because of how Oracle manages the extension, they support a wide range of unsupported PHP versions and the extension is dual released with PECL.

Maybe @cjbj can comment further on this.

Ah so it's still dual released? If it's indeed true this is a no go I'll close this, however I'd hope it would be possible to fix the potential [-Wundef] warnings which may arise in theory, just to be pedantic.

@KalleZ
Copy link
Member

KalleZ commented May 20, 2020

While its been sometime since its last release, I do think it is still the case. the [-Wundef] fixes should be a non issue to commit tho. I think zip and oci8 (potentially PDO_OCI8 too, tho I don't think Oracle ever officially took it over) are the only two extensions in the core that have "regular" PECL releases, but I could be wrong, better wait for @cjbj to have an opinion regarding legacy support before closing :)

@cjbj
Copy link
Contributor

cjbj commented May 21, 2020

OCI8 does land on PECL so it needs to compile with a range of PHP 7+ versions, and give graceful failure messages when people try to install with older versions. The #if -> #ifdef change should be fine.

PDO_OCI is under our wing, but doesn't have a separate PECL release.

@camporter
Copy link
Contributor

Sorry, @cjbj somewhat related, but I had tried to work on the php-based stubbing of the OCI8 extension in anticipation of PHP 8, but I'm not sure if that will be backwards compatible to do. Do you think it will be possible to add stubs for oci8 or no?

@nikic
Copy link
Member

nikic commented May 21, 2020

Just as a general policy point: All extensions bundled with php-src generally only need to be compatible with master. As a courtesy, we do allow retaining some compatibility code, but we do not actively maintain it ourselves. For example, the current code of ext/oci8 is not compatible with older versions, because it uses some PHP 8 APIs like RETURN_THROWS(). The responsibility of making this code compatible with older versions lies with the PECL maintainer, and they will have to figure out how they want to handle it (either with more #if's, or maybe by cutting a new major extension version for PHP 8, dunno).

So to answer your question @camporter: Yes, you can add stubs and I'd say this is even a de-facto requirement for PHP 8. If desired, the PECL maintainer can then restore compatibility with older versions by defining necessary polyfill macros and/or adding #if's to the stubs that select signatures based on PHP version. There is no fundamental incompatibility of stubs with older PHP versions (as we commit the generated files, and those files are mostly backwards-compatible). Just requires the usual work of maintaining extensions across versions :)

@cjbj
Copy link
Contributor

cjbj commented May 22, 2020

I appreciate the value-add that you are all putting into OCI8. The number of unread emails in my PHP folders is a reminder that I don't have the luxury of working with just one language anymore!

@Girgias Girgias force-pushed the oci8-cleanup-for-php-8 branch from ee9ca14 to 20992de Compare July 20, 2020 16:35
@Girgias
Copy link
Member Author

Girgias commented Jul 20, 2020

@cjbj Is there an easy way to compile OCI8 locally? As I'm pretty sure the callable ZPP change here would (or at least should) affect tests. Or you can just pull this branch locally to test and merge it?

@@ -152,18 +128,10 @@ PHP_FUNCTION(oci_define_by_name)
/* if (zend_hash_add(statement->defines, name, name_len, define, sizeof(php_oci_define), (void **)&tmp_define) == SUCCESS) { */
zvtmp = zend_string_init(name, name_len, 0);
if ((define = zend_hash_add_new_ptr(statement->defines, zvtmp, define)) != NULL) {
#if PHP_VERSION_ID < 70300
zend_string_release(zvtmp);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Was keeping the non *_ex() calls deliberate?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually no, let me change those back

@cjbj
Copy link
Contributor

cjbj commented Jul 21, 2020

@cjbj Is there an easy way to compile OCI8 locally? As I'm pretty sure the callable ZPP change here would (or at least should) affect tests. Or you can just pull this branch locally to test and merge it?

The callable changes are fine in the functional (manual) testing I ran. Yes, the error handling now gives a fatal error instead of a warning, but that's OK to me.

I wasn't sure why some of the macro cleanup changes kept the old code branch. Was that deliberate?

@Girgias Girgias force-pushed the oci8-cleanup-for-php-8 branch from 20992de to d9e378e Compare July 21, 2020 11:08
@Girgias
Copy link
Member Author

Girgias commented Jul 21, 2020

@cjbj Is there an easy way to compile OCI8 locally? As I'm pretty sure the callable ZPP change here would (or at least should) affect tests. Or you can just pull this branch locally to test and merge it?

The callable changes are fine in the functional (manual) testing I ran. Yes, the error handling now gives a fatal error instead of a warning, but that's OK to me.

Good to know :)

I wasn't sure why some of the macro cleanup changes kept the old code branch. Was that deliberate?

I don't remember if I did that on purpose or just my brain didn't do the correct thing, so I think I fixed all relevant issues.

@Girgias Girgias force-pushed the oci8-cleanup-for-php-8 branch from d9e378e to 97d5f9f Compare July 21, 2020 11:14
@cjbj
Copy link
Contributor

cjbj commented Jul 21, 2020

I'll review it again tomorrow. Thanks!

Comment on lines 1268 to 1272
#if PHP_VERSION_ID < 70300
zend_string_release(zvtmp);
#else
zend_string_release_ex(zvtmp, 0);
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the new branch be retained?

Comment on lines 1720 to 1724
#if PHP_VERSION_ID < 70300
zend_string_release(zvtmp);
#else
zend_string_release_ex(zvtmp, 0);
#endif
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the new branch be retained?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I missed those two when I did the other file.
Hopefully I fixed them all now. :)

@Girgias Girgias force-pushed the oci8-cleanup-for-php-8 branch from 97d5f9f to f5d6189 Compare July 22, 2020 01:11
@cjbj
Copy link
Contributor

cjbj commented Jul 22, 2020

I've merged this to master - thank you again.

The https://qa.php.net/pulls system doesn't seem to let me close the PR; it's silently doing nothing. Maybe I don't have access.

@remicollet
Copy link
Member

@cjbj closing as merged

@remicollet remicollet closed this Jul 22, 2020
@cjbj
Copy link
Contributor

cjbj commented Jul 22, 2020

@remicollet thank you.

1 similar comment
@cjbj
Copy link
Contributor

cjbj commented Jul 22, 2020

@remicollet thank you.

@Girgias Girgias deleted the oci8-cleanup-for-php-8 branch July 22, 2020 10:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants