Approach to Apple support
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Read the linked discussions in issues #5650 and #5693, then review how libc marks constants as unavailable across Apple platforms. The issue proposes treating constants present on macOS as available on all Apple platforms, but does not identify specific constants, files, or tests; done would require a decided support policy and corresponding changes.
Written by the indexing model from the issue text.
Description
As per the discussion here and here constants are marked as not present on Apple platforms e.g. iOS based on the presence of them of in Apple SDKs.
However they are available on all platforms. The headers just aren't there.
Removing them seems misguided because:
a) Not every app is going to be published to the App Store.
b) The choice about whether they should be used is ultimately a developer decision.
c) There are 100s of iOS apps which are making use of them.
d) There is a big difference between what Apple would like developers to do versus what they are actually upset about.
e) It seems an impossible situation where if Apple removes a header in say iOS 27 but you are targeting iOS 26 then you can't upgrade libc, nix, Tokio etc. Your entire codebase gets dictated by libc. There needs to be some long term stability for libc.
Given all of this it seems like honouring semvar (and thus support for older targets) should be the ultimate priority and if it is available on macOS it should be assumed to be available on all Apple platforms.
- Dominant language
- Rust
- Stars
- 2.6k
- Forks
- 1.3k
- Avg merge
- 2d 13h
- Merged PRs (30d)
- 27
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from rust-lang/libc
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
Maintainers usually reply within 1 day
-
riscv32gc-unknown-linux-gnu: `timex` uses the 32-bit `c_long` layout (144 bytes), glibc's riscv32 `struct timex` is 208 bytesPossibly taken @compiler-segfault claimed this 3 days ago. OpenC-bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
rust-lang/libc#5697 · 3 comments ·
Maintainers usually reply within 1 day
-
Expose `open_how` on AndroidPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
rust-lang/libc#5673 · 1 comment ·
Maintainers usually reply within 1 day
-
RTEMS: `dirfd` is not declaredPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
rust-lang/libc#5655 · 1 comment ·
Maintainers usually reply within 1 day
-
C-bug O-macos
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
rust-lang/libc#5650 · 16 comments ·
Maintainers usually reply within 1 day
Similar issues
-
good first issue help wanted program
Difficulty 2/5 1-3 hours Newbie friendliness 83/100
hffgzktbcc-blip/ounce-core#297 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
nautechsystems/nautilus_trader#5631 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 69/100
bytecodealliance/rustix#1736 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
longbridge/gpui-kit#3871 ·
Maintainers usually reply within 1 day
-
area:models enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
Maintainers usually reply within 1 day