Skip to content

Conversation

@wmamrak
Copy link

@wmamrak wmamrak commented Dec 15, 2025

This PR addresses a compilation warning of the form: warning C4244: '=': conversion from '__int64' to 'int', possible loss of data The expression gc_buffer->cur - gc_buffer->start produces a temporary of type ptrdiff_t, which is then assigned to an int. It causes said compilation warning when these types do not match.

@arnaud-lb
Copy link
Member

Thank you @wmamrak!

This looks right, but I believe that compiler warning fixes should target master.

@wmamrak
Copy link
Author

wmamrak commented Dec 16, 2025

I followed the rules from here, but I assume you know better 😃 . Should I edit the PR and change the base, or create a new PR? Thank you.

@arnaud-lb
Copy link
Member

arnaud-lb commented Dec 16, 2025

Yes you followed the rules right :) But it depends if we consider this a bug fix or a cosmetic change. In this case I think it's a cosmetic change because it's only masking a warning without fixing an actual bug. Which is fine, but only in master.

Please rebase on master and change the base, I will merge after that.

This PR addresses a compilation warning of the form:
warning C4244: '=': conversion from '__int64' to 'int', possible loss of data
The expression gc_buffer->cur - gc_buffer->start produces a temporary of type ptrdiff_t, which is then assigned to an int. It causes said compilation warning if these types do not match.
@wmamrak wmamrak force-pushed the fix-zend_get_gc_buffer_use-warning branch from 65fcd21 to ba99fec Compare December 16, 2025 17:32
@wmamrak wmamrak requested a review from TimWolla as a code owner December 16, 2025 17:32
@wmamrak wmamrak changed the base branch from PHP-8.3 to master December 16, 2025 17:33
@wmamrak
Copy link
Author

wmamrak commented Dec 16, 2025

Rebased and changed the base.

Copy link
Member

@TimWolla TimWolla left a comment

Choose a reason for hiding this comment

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

int is a terrible type and from what I see the gc internally uses uint32_t to store the n returned by the get_gc handler, so there additional type inconsistency. Would it instead make sense to adjust the signature of the get_gc() handler to either use uint32_t or to adjust everything to use ptrdiff_t instead?

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.

3 participants