-
Notifications
You must be signed in to change notification settings - Fork 7.9k
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
Conversation
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. |
While its been sometime since its last release, I do think it is still the case. the |
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 PDO_OCI is under our wing, but doesn't have a separate PECL release. |
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? |
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 :) |
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! |
ee9ca14
to
20992de
Compare
@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? |
ext/oci8/oci8_interface.c
Outdated
@@ -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); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
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? |
20992de
to
d9e378e
Compare
Good to know :)
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. |
d9e378e
to
97d5f9f
Compare
I'll review it again tomorrow. Thanks! |
ext/oci8/oci8_statement.c
Outdated
#if PHP_VERSION_ID < 70300 | ||
zend_string_release(zvtmp); | ||
#else | ||
zend_string_release_ex(zvtmp, 0); | ||
#endif |
There was a problem hiding this comment.
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?
ext/oci8/oci8_statement.c
Outdated
#if PHP_VERSION_ID < 70300 | ||
zend_string_release(zvtmp); | ||
#else | ||
zend_string_release_ex(zvtmp, 0); | ||
#endif |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. :)
97d5f9f
to
f5d6189
Compare
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. |
@cjbj closing as merged |
@remicollet thank you. |
1 similar comment
@remicollet thank you. |
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