0.1.4: retract 0.1.3 — that link error was clause 6.1 working (#4)

0.1.3 给这台机器不提供的两个接口定义了能力字:

    const kal_uintptr kal_fs_props   = 0;
    const kal_uintptr kal_task_props = 0;

理由是一个只「提问」的程序链接失败。⚠️ 那个失败是机制,不是缺陷。

规范 6.1:「实现不提供的接口,作为链接期定义是缺席的,使用它的
消费者链接失败。」6.2 的表把三个时机分得很清楚:

    链接 │ 未定义符号 │ 是否用了该实现不提供的接口
    运行 │ 能力字     │ 在**它提供的接口内**它如何表现

给一个没有任何操作的接口定义能力字,是在回答第二个问题,
而第一个问题根本不该被问到。程序于是越过了链接器存在的意义,
接着撞上未定义的 `kal_fs_open` —— 或者更糟,认为自己有一个
零能力的文件系统。SURFACE.txt 从另一侧说同一件事:实现
「导出它所提供的接口的名字,不导出其他任何以 kal_ 开头的名字」。

⭐ 我当时引了 6.2 的「未赋值的位读作零」来给自己背书,而那条讲的是
**它提供的接口**的字内部的位。结论被复查了,理由没有 —— 去读文件。

本提交的代码面与 0.1.2 逐行一致;多出来的只有把这次判断记下来的注释,
因为下一个人会遇到同样的链接错误,并且会想做同样的事。

Author: Sunrisepeak

mcpp.toml

@@ -14,7 +14,7 @@
 [package]
 namespace   = "mcpplibs"
 name        = "openkal-opensbi"
-version     = "0.1.3"
+version     = "0.1.4"
 description = "An implementation of openkal on the RISC-V Supervisor Binary Interface, portable across every machine whose firmware provides one"
 license     = "Apache-2.0"
 

src/kal.cpp

@@ -236,32 +236,34 @@ void* kal_alloc(kal_uintptr size, kal_uintptr align) {
 // rather than an omission.
 void kal_free(void*, kal_uintptr, kal_uintptr) {}
 
-// ── Capability words for the layers this machine does not have ──────────────
+// ── The interfaces this machine does not have are absent, and stay absent ───
 //
-// ⚠️ A BACKEND MUST DEFINE EVERY PROPERTY WORD, INCLUDING THE ONES THAT READ
-// ZERO, OR THE QUESTION ITSELF FAILS TO LINK.
+// ⚠️ NO `kal_fs_props`, NO `kal_task_props`, AND THAT IS THE MECHANISM RATHER
+// THAN AN OMISSION.
 //
-// The specification's queries are inline functions over these objects:
-//
-//     inline props properties() { return props{kal_fs_props}; }
-//
-// so a program that merely ASKS whether a filesystem exists takes the address
-// of `kal_fs_props`. Leaving it undefined on a machine that has no filesystem
-// makes the question unanswerable in the strongest sense: it does not link.
+// 0.1.3 defined both as zero, because a capability-querying program failed to
+// link against this backend:
 //
 //     ld.lld: error: undefined symbol: kal_fs_props
 //     >>> referenced by fs.cppm:136
 //     >>>               obj/main.o:(kal::fs::properties@openkal.fs())
 //
-// Measured while porting a capability-querying program to this backend. The
-// program contained no filesystem call at all — the reference came from the
-// query, which is the pattern the whole specification is built on.
+// That error is clause 6.1 working. "An interface that an implementation does
+// not provide is absent as a link-time definition, and a consumer that uses it
+// fails to link." Clause 6.2's table is explicit about which question each
+// mechanism answers: the LINKER answers "was an interface used that the
+// implementation does not provide", and a capability word answers "how does
+// this implementation behave WITHIN AN INTERFACE IT PROVIDES".
 //
-// Zero is the correct value and 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 case taken to its limit.
-const kal_uintptr kal_fs_props   = 0;
-const kal_uintptr kal_task_props = 0;
-
+// Defining the word for an interface with no operations answers the second
+// question about something that cannot be asked the first. The program then
+// proceeds past the point the linker existed to stop it at, and reaches
+// `kal_fs_open` — undefined — or worse, believes it has a filesystem with no
+// capabilities. SURFACE.txt says the same thing in the other direction: an
+// implementation "exports the names of the interfaces it provides and exports
+// no other name beginning with kal_".
+//
+// 0.1.3 is retracted. A program that asks this backend about a filesystem is a
+// program that should not build against this backend, and the graph is where
+// that is decided.
 }  // extern "C"