Skip to content

docs(13): 子集与零 libc 档是组合关系,不是互斥 - #467

Merged
Sunrisepeak merged 1 commit into
mainfrom
docs/zero-libc-subset-composes
Aug 20, 2026
Merged

docs(13): 子集与零 libc 档是组合关系,不是互斥#467
Sunrisepeak merged 1 commit into
mainfrom
docs/zero-libc-subset-composes

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

#466 的这一章里有一句断言,被同一个 PR 带来的 feature 推翻了:

⚠️ std-freestandingstd-freestanding-nolibc 服务于互斥的安排 …… 处在零 libc 档的工程根本用不了子集。

std-freestanding 0.4.0 的 nolibc feature 让子集在零 libc 档可用,实测 103 个头里的 94 个。那句话描述的是 0.4.0 之前的状态。

改了什么

  • 把「互斥」改为「组合」,并写明成因:libc++ 的 C 头包装头靠 #include_next 续到真正的头去取 size_tmbstate_ttime_tEOF;没有 C 库时这条链无处可续,于是死在缺类型上而不是缺头上——这正是从报错看不出成因的原因。
  • 补上板级支持包也能服务这一档(riscv-virt-rt 0.5.0 的 nolibc feature)。
  • 静默替换那条警告保留,但范围收窄为「直接std-freestanding-nolibc 与 C 库并用」,而非经由该 feature。

中英双份同步;check_docs_style.sh 通过。

#466 里这一章断言:

    ⚠️ `std-freestanding` 与 `std-freestanding-nolibc` 服务于**互斥**的
    安排 …… 处在零 libc 档的工程根本用不了子集。

这句话描述的是 std-freestanding 0.4.0 之前的状态,而 0.4.0 的 `nolibc`
feature 恰恰让子集在这一档可用——实测 103 个头里的 94 个。同一个 PR
同时带来了那个 feature 和这句否定它的话。

障碍从来不是子集需要一个 C 库:libc++ 为 C 头提供包装头,它们通过
`#include_next` 续到真正的头去取 `size_t`、`mbstate_t`、`time_t` 与
`EOF`;没有 C 库时这条链无处可续,于是死在缺**类型**上而不是缺头上,
这正是从报错看不出成因的原因。四个很小的头把链续上。

一并写入板级支持包也能服务这一档(riscv-virt-rt 0.5.0 的 `nolibc`
feature),理由与「为什么要有板级包」是同一条:UART 在哪、RAM 从哪开始、
哪个模拟器启动它,没有一条是 C 库事实。

静默替换那条警告仍然成立,但重新划定了范围:它说的是把
`std-freestanding-nolibc` **直接**与 C 库并用,而不是经由该 feature。
@Sunrisepeak
Sunrisepeak merged commit 6edf419 into main Aug 20, 2026
20 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants