Skip to content

Conversation

@cmb69
Copy link
Member

@cmb69 cmb69 commented May 8, 2020

We must not attempt to access arbitrary union members when retrieving
debug info, because that may not be valid. Therefore we do no longer
dereference pointer types inside of unions, but report their address as
integer instead.


This is an alternative solution to PR #5538; we show all union members, but do not dereference pointers. This is not quite in line with the behavior of void pointers, which are normally shown as own objects with a single int member, but might be more suitable for unions for brevity.

We must not attempt to access arbitrary union members when retrieving
debug info, because that may not be valid.  Therefore we do no longer
dereference pointer types inside of unions, but report their address as
integer instead.
["num"]=>
int(42)
["str"]=>
int(42)
Copy link
Member

@laruence laruence May 8, 2020

Choose a reason for hiding this comment

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

I think maybe a pointer format here is better, str => 0x2a?

Copy link
Member Author

Choose a reason for hiding this comment

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

I'm not happy treating this as IS_LONG, but I'm not sure that IS_STRING would be better. Actually, I think I'd like to have this as IS_PTR, but that would require adjustments to php_var_dump() etc.

Copy link
Member

Choose a reason for hiding this comment

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

yeah, IS_PTR seems better.. anyway, I think the current state is also okey, thanks

ext/ffi/ffi.c Outdated
goto again;
case ZEND_FFI_TYPE_POINTER:
if (debug_union) {
ZVAL_LONG(rv, (uintptr_t)*(void**)ptr);
Copy link
Member

Choose a reason for hiding this comment

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

I mean here, ZVAL_STR(rv, zend_strpprintf(“%p”, ptr))?

@cmb69 cmb69 added the Bug label May 8, 2020
@PeratX
Copy link

PeratX commented May 8, 2020

When access pointer value inside union, like

typedef union {
   int32_t intValue;
   char* stringValue;
}

$union->stringValue; //causes segfault

Is this solved?

@cmb69
Copy link
Member Author

cmb69 commented May 8, 2020

@PeratX, no this issue is not solved, and likely will not be. It is the programmer's responsibility to not dereference uninitialized pointers. This fix just patches the case where some potentially large structure is output for debugging purposes (e.g. var_dump()).

@PeratX
Copy link

PeratX commented May 8, 2020

Yes, I agree with you.
But can we introduce a setType("char*") method to union?
Like $struct->union->setType("char*");, if the programmer trys accessing an invalid value, a fatal error will be produced.

@cmb69
Copy link
Member Author

cmb69 commented May 11, 2020

@dstogov, @nikic, what do you think of this as alternative to PR #5538? We could also present the pointer value as string (%p format) like suggested by @laruence.

@nikic
Copy link
Member

nikic commented May 11, 2020

Looks good to me generally. I agree that printing this as something like "0xDEADBEEF" would make it a bit more clear that it's a pointer.

@cmb69
Copy link
Member Author

cmb69 commented May 11, 2020

Thanks! Applied as d530087.

@cmb69 cmb69 closed this May 11, 2020
@cmb69 cmb69 deleted the cmb/79571-2 branch May 11, 2020 14:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants