Skip to content

fix: define every capability word, including the ones that read zero - #2

Merged
Sunrisepeak merged 1 commit into
mainfrom
fix/define-every-capability-word
Aug 24, 2026
Merged

fix: define every capability word, including the ones that read zero#2
Sunrisepeak merged 1 commit into
mainfrom
fix/define-every-capability-word

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Summary

Measured while porting a capability-querying program to this backend:

ld.lld: error: undefined symbol: kal_fs_props
>>> referenced by fs.cppm:136
>>>               obj/main.o:(kal::fs::properties@openkal.fs())

ld.lld: error: undefined symbol: kal_task_props

The program contains no filesystem call at all. The reference comes from the
question, because the specification's queries are inline functions over these
objects:

inline props properties() { return props{kal_fs_props}; }

A program that merely asks whether this machine has a filesystem takes the
address of kal_fs_props. Leaving it undefined on a machine that has none makes
the question unanswerable in the strongest sense: it does not link.

Asking rather than assuming is the pattern the whole specification is built on.
A backend that omits the property words for the layers it lacks defeats that
pattern on exactly the class of platform it exists to serve.

Zero is the correct value, and it is already the specified reading — "an
unassigned position reads as zero, so that a program compiled against a later
specification behaves correctly against an earlier implementation"
. A machine
with no filesystem and no scheduler is that sentence taken to its limit.

Test plan

  • Reproduced: a riscv64-none-elf build of a program whose only reference is
    kal::fs::properties() / kal::task::properties() fails to link without this
  • CI

⚠️ Reading the specification twice did not surface this; writing one program and
running it once did.

⚠️ 在把一个「查询能力」的可移植程序移到这个后端时实测:

    ld.lld: error: undefined symbol: kal_fs_props
    >>> referenced by fs.cppm:136
    >>>               obj/main.o:(kal::fs::properties@openkal.fs())

    ld.lld: error: undefined symbol: kal_task_props

那个程序**一次文件系统调用都没有**。引用来自「询问」本身 ——
规范的查询是这些对象上的 inline 函数:

    inline props properties() { return props{kal_fs_props}; }

所以一个只是**问**「这台机器有没有文件系统」的程序,就会取 `kal_fs_props`
的地址。在一台没有文件系统的机器上不定义它,等于让这个问题以最强的方式
无法回答:它链接不过去。

⭐ 而「询问而不假定」正是整个规范建立其上的模式。一个后端不定义它没有的那些
层的属性字,就使该模式在它最需要服务的那类平台上失效。

零是正确的值,而且已经是规范里写下的读法:「未赋值的位读作零,
以使一个按更晚规范编译的程序在更早的实现上行为正确」。
一台没有文件系统也没有调度器的机器,是这句话推到极限的情形。

⚠️ 读规范两轮没有发现这一条;写一个程序跑一次就挖出来了。
这在本生态里是同一教训的第三次。
@Sunrisepeak
Sunrisepeak merged commit 0246d7b into main Aug 24, 2026
3 checks passed
@Sunrisepeak Sunrisepeak mentioned this pull request Aug 24, 2026
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.

1 participant