Closed petervdonovan closed 1 week ago
[!WARNING]
Rate limit exceeded
@petervdonovan has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 44 minutes and 51 seconds before requesting another review.
How to resolve this issue?
After the wait time has elapsed, a review can be triggered using the `@coderabbitai review` command as a PR comment. Alternatively, push new commits to this PR. We recommend that you space out your commits to avoid hitting the rate limit.How do rate limits work?
CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our [FAQ](https://coderabbit.ai/docs/faq) for further information.Commits
Files that changed from the base of the PR and between 6c51f7d53cf615deba957d8906894711ca0173a7 and 76408229db1e096d586f96eb7ea5259de6405220.
The changes in pqueue_tag.c
involve modifying how elements and priorities are cast to uintptr_t
before converting them to pqueue_pri_t
or accessing their tag field. These adjustments aim to fix build errors on 32-bit systems.
File Path | Change Summary |
---|---|
core/utils/pqueue_tag.c |
Updated pqueue_tag_get_priority to cast element to uintptr_t first before pqueue_pri_t conversion. Adjusted pqueue_tag_compare to cast priorities to uintptr_t before accessing the tag field. |
Objective (Issue #) | Addressed | Explanation |
---|---|---|
Fix build errors on 32-bit systems (#447) | ✅ |
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?
Closing in favor of #450
I am reopening this because a Zephyr test failure #450 on a 32-bit platform indicates that this solution may be better.
Closes #447.
Summary: I reviewed the
pqueue_tag
code that Edward and Byeong-gil worked on, and I determined that it was safe because I think that in practice, there are essentially no important platforms on which it will not work properly to cast a void pointer to anunsigned long long
and back. This is because anunsigned long long
is always at least 64 bits, and pointers in the real world are never larger than 64 bits.Therefore, I decided to suppress the error using an intermediate cast to
uintptr_t
.Summary by CodeRabbit