Skip to content

Fix assertion failure when var_dump'ing void FFI result #10568

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

Merged
merged 1 commit into from
Feb 13, 2023

Conversation

nielsdos
Copy link
Member

No description provided.

Comment on lines +9 to +11
} catch (Throwable $_) {
die('skip libc.so.6 not available');
}
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
} catch (Throwable $_) {
die('skip libc.so.6 not available');
}
} catch (Throwable) {
die('skip libc.so.6 not available');
}

You can omit the variable as of PHP 8.0

Copy link
Member Author

Choose a reason for hiding this comment

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

Thanks, I'll wait for other reviews to come in and then I'll update this

Copy link
Member

@dstogov dstogov left a comment

Choose a reason for hiding this comment

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

I think it's better to return NULL for void in first pace.

diff --git a/ext/ffi/ffi.c b/ext/ffi/ffi.c
index 107d2862c1..3ee3c27638 100644
--- a/ext/ffi/ffi.c
+++ b/ext/ffi/ffi.c
@@ -2777,7 +2777,11 @@ static ZEND_FUNCTION(ffi_trampoline) /* {{{ */
 		free_alloca(arg_values, arg_values_use_heap);
 	}
 
-	zend_ffi_cdata_to_zval(NULL, ret, ZEND_FFI_TYPE(type->func.ret_type), BP_VAR_R, return_value, 0, 1, 0);
+	if (ZEND_FFI_TYPE(type->func.ret_type)->kind != ZEND_FFI_TYPE_VOID) {
+		zend_ffi_cdata_to_zval(NULL, ret, ZEND_FFI_TYPE(type->func.ret_type), BP_VAR_R, return_value, 0, 1, 0);
+	} else {
+		ZVAL_NULL(return_value);
+	}
 	free_alloca(ret, ret_use_heap);
 
 exit:

I don't care about $_ in tests, but it's better to update it, if this makes questions.

Please , update the PR, or I can do this myself a bit later.

@nielsdos
Copy link
Member Author

I'll check it tonight, thanks

@nielsdos
Copy link
Member Author

I think it's better to return NULL for void in first pace.

I think that would be a backward incompatibility break.
Currently, the ffi call in my test returns an object(FFI\CData:void).
To compare, if you do var_dump with my fix you get:

object(FFI\CData:void)#2 (0) {
}

and with your fix you get NULL.
As a user of FFI I would always expect to get an FFI type back instead of having to deal with a special case of a NULL return.

The root cause of this bug is in the get_debug_info function (that var_dump uses), not in the fact that there's a void type.
So I don't think it's right to fix it by setting the return value to NULL in the trampoline.

If you insist on your fix, I will change this PR to your fix instead of mine. I just wanted to share my perspective about this :)

@dstogov
Copy link
Member

dstogov commented Feb 13, 2023

OK. Even if this "void" was returned by mistake, keeping compatibility makes sense.
Lets keep your fix for PHP-8.1 and PHP-8.2 but change this to NULL in master.

Do you agree?

@nielsdos
Copy link
Member Author

Yes, I agree. Do you want me to open a second PR that targets master-only, or do you change it when merging up?

@dstogov
Copy link
Member

dstogov commented Feb 13, 2023

No thanks. I'll do this myself tomorrow.

@dstogov dstogov merged commit 1a5fc6e into php:PHP-8.1 Feb 13, 2023
dstogov added a commit that referenced this pull request Feb 13, 2023
* PHP-8.1:
  Fix assertion failure when var_dump'ing void FFI result (#10568)
dstogov added a commit that referenced this pull request Feb 13, 2023
* PHP-8.2:
  Fix assertion failure when var_dump'ing void FFI result (#10568)
@dstogov
Copy link
Member

dstogov commented Feb 13, 2023

#10579

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants