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

android 32 bits fix stat struct proposal. #3286

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

devnexen
Copy link
Contributor

close #3285

@rustbot
Copy link
Collaborator

rustbot commented Jun 28, 2023

r? @JohnTitor

(rustbot has picked a reviewer for you, use r? to override)

@JohnTitor
Copy link
Member

@bors r+

@bors
Copy link
Contributor

bors commented Jan 8, 2024

📌 Commit 57bfcd8 has been approved by JohnTitor

It is now in the queue for this repository.

@bors
Copy link
Contributor

bors commented Jan 8, 2024

⌛ Testing commit 57bfcd8 with merge 3fac855...

bors added a commit that referenced this pull request Jan 8, 2024
android 32 bits fix stat struct proposal.

close #3285
@bors
Copy link
Contributor

bors commented Jan 8, 2024

💔 Test failed - checks-actions

@tgross35
Copy link
Contributor

Looks like this doesn't agree with the libc we are checking against. I think @danielocfb was saying that we should use e.g. dev_t rather than c_ulong

@rustbot author

@tgross35
Copy link
Contributor

@maurer would you mind looking at this? This would be a breaking change to stat for libc 1.0.

@maurer
Copy link

maurer commented Nov 21, 2024

This change is incorrect - the bionic stat definition looks like the left hand side for 32-bit platforms.

I can comment over on the issue, but the reason this one is different is because the actual value returned here is not an ino_t. Even outside bionic (which you should use as the source of truth for what Android libc structures look like), 32-bit ARM musl has a similar header which makes the fact that this field is truncated more explicit.

It looks like there may be a couple places where using the "right type" is plausible (e.g. musl thinks that using dev_t for the first one could work), and I could talk to the bionic maintainer about making this switch if it would be helpful, but the proposed change would actually just flat out work incorrectly, the new proposed structure has the wrong offsets.

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.

android: Can we use proper libc typedefs in stat definition?
6 participants