Skip to content

README: three macro families, and what __openkal__ may be used for - #35

Merged
Sunrisepeak merged 1 commit into
mainfrom
docs/c-environment
Sep 17, 2026
Merged

Sunrisepeak merged 1 commit into
mainfrom
docs/c-environment

Conversation

@Sunrisepeak

Copy link
Copy Markdown
Member

Documents only. Revises rule 4 of "What a program built on openkal may assume": the kernel interface is stated by __openkal__ (defined where the resolved kernel-abi is openkal), the C environment by the C library layer, the system by the triple. Using __openkal__ to select a header or infer the platform remains forbidden.

.agents/docs/2026-09-18-openkal-c-environment-and-personalities-design.md is the design this follows, with its review record and self-review; 2026-09-18-c-environment-execution-plan.md is the plan. No declaration changes, so no version change.

The section said that no macro states that a program is built on openkal. That
is too strong: the kernel interface is a layer like the others, and a statement
about it is a fact. What the rule protects is the separation of the three
questions, so the rule now states the separation: __openkal__ says kal_* may be
called, the C library layer states the C environment, the triple states the
system. Using __openkal__ to select a header or to infer the platform remains
forbidden, and __has_include(<openkal/version.h>) reaches the same decision
today.

.agents/docs carries the design this follows and its execution plan.
@Sunrisepeak
Sunrisepeak merged commit 7136a41 into main Sep 17, 2026
12 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.

1 participant