Skip to content
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

Handle operations on the addresses of non-array types #1480

Open
wants to merge 14 commits into
base: master
Choose a base branch
from

Conversation

karoliineh
Copy link
Member

Solves #1421

@karoliineh karoliineh added the bug label May 23, 2024
@karoliineh karoliineh linked an issue May 23, 2024 that may be closed by this pull request
@karoliineh karoliineh marked this pull request as draft May 23, 2024 09:50
@sim642 sim642 self-requested a review May 24, 2024 09:09
@karoliineh karoliineh marked this pull request as ready for review May 24, 2024 21:24
@karoliineh
Copy link
Member Author

I was satisfied with the fix that I proposed here, but I think @sim642 was unsure if it was the right fix for this. @michael-schwarz, could you please take a look at it? Do you think this fix is reasonable?

@michael-schwarz michael-schwarz self-requested a review July 16, 2024 13:11
begin match IdxDom.(to_bool (eq f_offset (neg (iDtoIdx n)))) with
| Some true -> `NoOffset
| _ when isArrayType f.ftype -> `Field (f, `Index (n, `NoOffset))
| _ when GobOption.exists (Z.equal Z.zero) (ID.to_int n) -> `NoOffset (* adding (or subtracting) 0 to any type of pointer is ok *)
Copy link
Member

Choose a reason for hiding this comment

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

As it stands this means that the case of n being -f_offset is handled the same as the case where n is 0?
That seems odd.

Would this not have to be Field(f,NoOffset) here?

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.

Crash on pthread_mutex_lock with complicated argument
2 participants