sp.h1：高品質で超ポータブルな C 標準ライブラリの開発

概要

過去 1 年間にわたって開発された、C プログラミング言語における新たな基準となる単一ヘッダー形式のライブラリです。

• 名称:

  sp.h1

• 規模: ソースコード約 15,000 行（単一ヘッダー形式）
• ライセンス・公開元: GitHub で公開済み
• 特徴:

  • libc

    のラッパーではない。
  • 状況に応じて

    libc

    を使用するかしないかを選択可能（デフォルトは不使用）。
  • 野球関連の機能拡張ライブラリも多数付属する。

基本原理

システムコールへの直接アクセス

すべての C ライブラリは、利用可能な最低限の基底機能（システムコール）に対して直接記述されるべきです。

• OS とコードの間に蓄積された古い実装（くず屑）をシミュレートしたり生成したりする做法は、有用性も生産性もないと判断されます。

libc

は能動的に有害である

libc

• 非同期プログラミングの重要性増大: IO 処理において「高速さ」はレジスタ割り当てではなく、適切なカーネル機能の使用にあるためです。
• 古臭いインターフェース:

  • FILE*

    型のインターフェース（IO の根本単位が不適切）。
  • 部分文字列を「悪質」とみなす設計。
  • これらは単なる不便さを超え、有害です。
• 方針:

  sp.h1

  はこれらの依存関係を断ち切ることに注力しています。

ヒープは存在しない（メモリ割り当て）

型定義にはアロケータ機能の基底機能が組み込まれています。

typedef enum {
    SP_ALLOCATOR_MODE_ALLOC,
    SP_ALLOCATOR_MODE_FREE,
    SP_ALLOCATOR_MODE_RESIZE,
} sp_mem_alloc_mode_t;

SP_TYPEDEF_FN(
    void*,
    sp_allocator_fn_t,
    void* user_data, sp_mem_alloc_mode_t mode, u64 size, void* ptr
);

typedef struct sp_allocator_t {
    sp_allocator_fn_t on_alloc;
    void* user_data;
} sp_mem_t;

• 事実の再認識: プログラムが「無から任意量のメモリを割り当てられる」という能力は幻想です。OS はページ単位でメモリを割り当てます。

• malloc()

  を通じて動作するランタイムは、「ページサイズ未満の割当が可能」という幻覚を提供しているに過ぎません。
• メモリは「ランタイム」や「ヒープ」のものではなく、プログラムの所有物です。
• ヒープ割り当てを望むのは自由ですが、これを「非選択型」から**「選択型」**へ転換することが推奨されます。

nullptr

文字列（ヌル終端文字列）は悪魔の業である

ヌル終端文字列 (

\0

• オーナーシップを持たない部分文字列の返還ができない。
• O(1) の時間複雑度で文字列の長さを知る必要がある場合に不利。
• レクサーやパーサが人間工学に優れたビューを返せない。
• インバリッドな中間値を含まずに安全に文字列を構築できない。

代替案:

sp_str_t

• 既存 API との互換性の問題は一時的でしたが、現在は意味がないと見直されています。
• パフォーマンスと人間工学を両立したコード例:

sp_str_t content = sp_zero;
sp_io_read_file(mem, path, &content);

sp_ht(sp_str_t, u32) counts = sp_zero;
sp_str_ht_init(mem, counts);
sp_da(sp_str_t) lines = sp_str_split_c8(mem, content, '\n');
sp_da_for(lines, i) {
    sp_da(sp_str_t) words = sp_str_split_c8(mem, lines[i], ' ');

    sp_da_for(words, j) {
        u32* count = sp_str_ht_get(counts, words[j]);
        if (count) {
            *count = *count + 1;
        } else {
            sp_str_ht_insert(counts, words[j], 1);
        }
    }
}

このコードはソースバッファからデータを複製することなく動作し、高級言語のような可読性を保ちつつ最大のパフォーマンスを実現します。

ソフトウェアの一部であり、外側ではない

sp.h1

• コア部分: 約 40 のシステムコールのみを使用（唯一のプラットフォーム固有依存）。
• 配布形式: 設定不要の単一ファイル (

  header

  ) で完結。
• 構造: 極めて整理されており、

  @tags

  によるタグ付けで検索可能（LLM や人間向け）。
• ネームスペース: すべての関数が適切に名前空間化されている。

このアプローチにより、OS の複雑な幻想ではなく、真実であるものを薄いながらも有用なものとして統合し、その上から機能構築を行っています。

極めて高い互換性を保つ

sp.h1

• プラットフォーム対応: Linux, Windows, macOS, WASM (ブラウザ内)。
• ツールチェーン: MSVC, MinGW, TCC など。
• 環境適応:

  libc

  不使用環境、Cosmopolitan OS など、奇妙な環境も対応。
• サイズと性能: ライブラリが巨大であるからではなく、小さくあるからこそできるすべてを実現しています。

明示的であること

暗黙の動作ではなく、すべての挙動を明示する設計を採用しています：

• エラーは常に返され、呼び出し側で処理される。
• 変更可能なグローバル状態が存在しない。
• メモリ割り当て関数はユーザー定義のアロケータを受け取る。
• メモリはゼロで初期化される。

非目標（ここまでは対応しない）

既存のインターフェースへの準拠

• これは

  libc

  ではありません。
• 必要な場合のみ尊重しますが、

  libc

  使用プログラムへの埋め込みでも無侵入かつ動作保証されます。

• libc

  のような挙動を期待すべきものではありません。

不明瞭なアーキテクチャや OS への対応

• 現在の焦点:

  x86_64

  ,

  aarch64

  。
• WASM: 重要性が増していますが、ネイティブターゲットに次点です。
• 方針: 非推奨プラットフォームへの対応は行わず、合理的なパッチであればマージを検討しますが、膨らませる予定はありません。

パフォーマンス

• 立ち位置: 「低レベルの計算依存型パフォーマンスにおいて、搾り取る価値以上の果汁はない」。
• 設計の難しさ: 未知のハードウェアと使用ケースに対する最適なパフォーマンスを担保するのは困難であり、コードが複雑化します。
• 推奨: パフォーマンスが極めて重要な場合は、実際の用途とハードウェアに特化したコードを使用すべきです。

除外される最適化:

• SIMD によるハッシュテーブルのリ書き換え。

• LIKELY

  やインラインによる微細なコンパイラ手動調整。

検討されている機能:

• 最適化およびゼロコピー IO のための正しい抽象。
• データコピーを不要とする API の設計。

バグ修正も優先されますが、過度な最適化には反対です（理由は単に「忙しい」ため）。

お別れの言葉：C はシンプルであるために価値がある

システムプログラミングにおいて C よりも良い言語は存在しないでしょうか？答えはいいえです。なぜなら C こそが以下の条件を唯一満たすから：

• 任意のマシンコードに直接コンパイルできる。
• 最先端の最適化コンパイラエコシステムが存在する。
• OS および大部分のライブラリと同じ言語で記述されている。

C の価値は、単なるレガシーの上に構築されているからではなく、**「シンプルであること」**にあります。

• LLVM 等の存在により、技術的には誰でも最先端のコンパイラを持ち得ます。
• 他の言語には型系やツールが存在します。
• しかし、そのようなサポートが魔法のように機能し、最適化されつつネイティブにアクセスできるプラットフォームは C です。

皆さんと一緒に取り組んでいきたい

このライブラリ開発者として皆様と連携することを楽しみにしています。

• 支援内容:
  • 非慣用的な環境への移植支援。
  • 疑問点に関する徹底した解説。
  • フィードバックへの丁寧な対応。
• 私の姿勢:
  • システムプログラミングの天才ではありませんが、多くの誤解から学び、多大な努力と楽しみを経て開発されたソフトウェアです。
  • 「プログラミングが下手」と評されようとも、耳を傾けてまいります。

連絡先:

• Discord サーバー: お待ちしています。
• IRC チャンネル:

  #sp

  。
• メール: ドメインはサイトと同じで、ハンドルネームは私の姓です。