ジグライブラリ

概要

Zig のmainブランチにおける 2026年の最新変更点 まとめ
libcサブプロジェクト の進展とCコード削除の進行状況
Zig独自のlibc提供 による利点と最適化
Io制御やリソースリーク検出 の将来的可能性
バグ報告のガイドライン と感謝の意

2026年 Zig mainブランチ主な変更点

Zig libcサブプロジェクト の進展
- 複数の貢献者による積極的なコード整理
- libc関数 をZig標準ライブラリのラッパーとして実装
  - 例: memcpy や atan2 などの1対1マッピング
  - strnlen のような汎用関数のラップも実施
    - 例:
```
fn strnlen(str: [*:0]const c_char, max: usize) callconv(.c) usize {
    return std.mem.findScalar(u8, @ptrCast(str[0..max]), 0) orelse max;
}
```
Cソースファイルの削減
- 約 250ファイル削除、残り 2032ファイル
- Zigの 独立性向上、 コンパイル速度改善、 インストールサイズ削減
- 静的リンク時の バイナリサイズ低減
Zig Compilation Unit (ZCU)共有化
- libc関数 が他のZigコードと同じZCUでコンパイル
- 冗長コード削減、 最適化 の促進
- LTO（リンクタイム最適化） に類似した効果をフロントエンドで実現
I/O制御の将来的可能性
- std.Ioの変更 と連携したI/O制御の柔軟性
  - 例: 全てのread/writeを io_uringイベントループ 参加に強制
  - リソースリーク検出 の有効化
- 現時点では 構想段階、今後の実験に期待
libc-testへの感謝
- Szabolcs Nagy によるlibc-testプロジェクト
- 数学関数の 後退防止 に寄与
バグ報告のガイドライン
- Zigが static libc provider へ移行中
- musl, mingw-w64, wasi-libc のlibc機能に問題があれば
  - まず Zigにバグ報告 を推奨
  - 独立libc実装プロジェクトのメンテナへ不要な報告防止
スローガン
- Abolish ICE （内部コンパイラエラーの撲滅）

Hackerたちの意見

「さらに、この作業が最近のstd.Ioの変更と組み合わさることで、ユーザーがlibcのI/Oの動作をシームレスに制御できる可能性があるんだ。例えば、すべてのreadとwriteの呼び出しをio_uringのイベントループに参加させることができる。」これはワクワクするね！特にkqueueに興味があるけど、この引用もそれに当てはまると思う。

確かに面白いアイデアだけど、移植されたコードについて考えると、glibcやmuslのCVEを常に気にしなきゃいけないんじゃないかって思っちゃう。Zigの実装にも適用されるかどうかを判断する必要があるよね。

└

でも、すでに自分たちの標準ライブラリのためにそれをやらなきゃいけないんだよね。共有コードパス（例えば数学）の場合、潜在的なバグが厳密に少なくなる。

一番下に「ICEを廃止しろ」って書いてある。明らかにBad Bunnyのファンだね、私もそうだから。

└

私も内部コンパイラエラーにはうんざりだよ。

└

私も侵入対策電子機器にはうんざりだよ。ネットランナーたちのことを考えてみて。

└

同じ日のうちに、家でこのデブログを書いている間に、私の街では選挙で選ばれた公 officials の意向に反して、軍が平和な抗議者たち、私の妻も含めて、何の前触れもなく催涙ガスを発射しました。これは私が自分のプラットフォームを使って押し付けている仮想的な政治的アジェンダではありません。来週末に平和的に抗議に出かけて、アレックス・プレッティのように撃たれる可能性もゼロではありません。ICEに撃たれたら、Zigプロジェクトには良くない影響が出るのは言うまでもありません。そして、彼らはほぼ文字通り私の家の前まで戦いを持ち込んできました。ICEを廃止しよう。

└

私も内燃機関にはうんざりだよ、20世紀の産物だしね。

└

誰かが政治のことをやるのは別に構わないよ。プライバシー重視だし、ソフトウェアの企業モデルには反対派だからね。スタールマンの大ファンだし。でも、Zigのことには政治を持ち込まない方がいいと思う。ICEが何かも知らないし、さっきちょっと読んだだけ。これは力の誇示だよ。「俺はアメリカ人だし、ソフトウェアを作ってるから、俺の政治を押し付けるぞ」って感じ。つまり、同じような力を示すには、Zigと同じくらい影響力のあるソフトウェアを作らないと、俺の国の agenda を押し付けられないってことだ。まあ、そういうことをやらせてもらうよ。政治は政治のフォーラムに、コードはコードに分けようぜ。

「libcの境界を越えてLTO（リンク時最適化）を有効にするような感じだけど、フロントエンドでちゃんと行われるから、遅すぎるリンカーではない。」なんでリンカーは遅すぎるの？Zigは、例えばLLVM IRを使っているリンカーではできないフロントエンドでの最適化ができるの？

└

インライン化やデッドコードの削除ができるはずだと思うけど、最適化された静的ライブラリに対してリンク時には実現できないんじゃないかな。

250のCファイルが削除された。2032個残ってる。Zigがlibcを内部から少しずつ食べていくのを見るのは、長期的に追うにはかなり満足感のあるプロジェクトだね。

└

Zigのことはずっと尊敬してるんだ。多くの言語がCの代替を主張するけど、Zigは実際にそれを大規模に実現するための合理的なプランを持っているように見える二つ目の言語だよ。C ABIとの連携がかなり簡単だし、ZigとCをシームレスに統合できるビルドシステムもある。さらに、実際に驚くほどうまく動くtranslate-cもある。唯一の欠点は、既存のCコードベースと99%互換性がないことだったけど…それはC++の戦略で、そんなプランを持っている言語は他に思いつかないな。正直言うと、ZigはCの相対的なシンプルさを保ちながら、言語特有の落とし穴を避ける方が賢い選択だったと思う。

これはCライブラリをリンクするZigプロジェクトにとって非常にワクワクする話だね。ただ、次のケースについて気になるんだけど：Windows向けにMinGWを使ってCプログラムを作っていて、Zigをクロスコンパイラとしてだけ使っているとする。MinGWのlibc実装を静的にリンクする方法はあるの？それとも、これがなくなって、外見上はMinGWに見えても、静的にリンクできるのはziglibcだけになるのかな？

└

このユースケースは変わってないよ。-target x86_64-windows-gnu -lcを指定すると、いくつかのlibc関数はZigから提供され、いくつかはvendored mingw-w64のCファイルから提供されるから、mingw-w64を別にインストールする必要はない。Zigがすべてを提供してくれるよ。--libc libc.txtを渡せば、別のmingw-w64インストールや、自分のlibcインストールにリンクすることもできる。どちらの状況も変わってない。

これって、長期的にはZigがOpenBSDで動かないってこと？だってOpenBSDは直接のシステムコールをブロックして、すべてをlibc経由に強制するんじゃないの？

└

https://news.ycombinator.com/reply?id=46864849&goto=item%3Fi...

└

これは静的libcにだけ影響するよ。-dynamic -lcを渡すと、libcの関数はターゲットシステムから提供される。一部のシステムは動的libcしかサポートしてない、例えばmacOSとかね。OpenBSDは実際には静的libcをサポートしてると思うけど。

誰かが考えたことがあると思うけど、なんでこれをzlibcって呼ばないの？ :-)

└

「libz」が結構好きだな。

└

zlibと混同しないようにかな？ https://www.zlib.net/

libcには怖い部分がたくさんあるから、これは本当にワクワクするプロジェクトだね。

└

便利な関数もたくさんあるよ。「memfrob」とか「strfry」とかね。Zigのlibcでもそれらが使えるといいな。もちろん冗談だけど。残念ながら、あれはglibcにしかないからね.. :)

ハクソク

ジグライブラリ

概要

2026年 Zig mainブランチ主な変更点

Hackerたちの意見