C、C++、Swiftを安全に併用する方法

C、C++、Swiftを併用する際にアプリの安全性を向上させる方法を学びましょう。安全でないCやC++のAPIが呼び出されているSwiftコード内の箇所を特定してより安全に呼び出す方法や、アプリの既存のCおよびC++コードをデフォルトでより安全にする方法を紹介します。

リソース

関連ビデオ

WWDC25

Swiftによるメモリ使用量とパフォーマンスの向上

こんにちは Yeoulです AppleのSecure Language Extensionチームのマネージャーですアプリを作成する際はセキュリティを優先することが重要ですこれは潜在的な攻撃者からユーザーの個人情報を保護することを意味しますこれらの脅威アクターは多くの場合安全でない言語である CやC++で書かれたコードの脆弱性を悪用します明るい面としてはアプリですでにSwiftを使用している場合言語はデフォルトで安全ですこれは素晴らしいニュースです

しかし新しいコードをすべて Swiftで書いている場合でもアプリにはコードベースの古い部分にまだCやC++のコードが含まれている可能性がありますまたは外部ライブラリに依存する場合がありますこれらの言語が混在する場合 Swiftの安全性保証が損なわれないようにすることが重要です簡単にまとめると生のポインタを受け取ったり返したりするCやC++の関数を安全に呼び出すのは非常に難しいという問題がありますこれらの関数を誤って呼び出すとバッファオーバーフローや解放後の使用といったセキュリティや安定性のバグを引き起こす可能性があります

このため CやC++からのポインタは Swiftではunsafe型としてインポートされますたとえば Cの整数ポインタは UnsafeMutablePointerとしてインポートされます Swiftは型名にわざと unsafeを入れていますそれにより関数を呼び出すときに通常の安全性保証に頼れないことを知ることができますただしいくつかの関数をSwiftから安全に呼び出せることはわかっていますしかしこれまで CとC++にはその方法を伝える術がありませんでしたこれがこのセッションの内容です

まず Swiftの安全でない呼び出しを特定するのに役立つ新しい機能 Strict Memory Safetyについて説明します

次に CとC++の関数に注釈を付けて不足している情報を伝えることで Swiftがそれらを安全に呼び出せるようにする方法を説明します次にカスタムC++の型に注釈を付けて安全にインポートする方法を説明します最後に Cベースの言語をSwiftのように安全にすることは不可能ですが CとC++のコードを少しでも安全にするためのツールをいくつか紹介します

Swift 6.2には安全でないCおよびC++関数の呼び出しの検出に役立つ新機能がありますこれを私が作ったアプリで実演しますこのアプリではペットのかわいいプロフィール写真をユーザーが共有できますこのアプリは愛犬のミドルネームのような機密性が非常に高い個人情報にアクセスできるので安全に保つ必要がありますアプリはSwiftで書かれていますただしカスタム画像フィルタを適用するために CとC++コードも呼び出しますアプリ内でCやC++への安全でない呼び出しをすべて見つけそれらを安全にする必要があります厄介なのはそのような呼び出しを見つけるのが難しい場合があることです Swiftはデフォルトでは安全ですが特にCやC++と相互運用する場合安全でないコンストラクタを使用できますたとえば水面下では &imageDataは UnsafeMutablePointerを作成しますがこれは名前から安全でないことがわかりますしかしこのコードを読んでいるときにそれに気付くのはそれほど簡単ではありません安全でない関数へのすべての呼び出しを見つけるために Swift 6.2では Strict Memory Safetyと呼ばれる新しいコンパイラモードを使用できます Strict Memory Safetyがオンの場合コンパイラは安全でないコードを理由を説明するノードとともに警告します

Strict Memory Safetyはデフォルトでは有効になっていませんが私のアプリはセキュリティに配慮するので私は間違いなくオンにするつもりです Xcodeでチェックしましょう

プロジェクトのビルド設定でをに切り替えてオプトインします

再ビルドするとコンパイラは安全でないコンストラクタを見つけるのに役立つ警告を発します

新しい警告がいくつか出てきましたこの安全でないコードのほとんどは CとC++のポインタに関係しています

Swiftからこれらのポインタを使う関数を安全に呼び出す方法を説明します

しかしその前に CとC++のポインタを安全に使うのが難しい理由をお話しします

ポインタは強力で便利なツールですコピーすることなくメモリを調べる能力を与えてくれますしかし安全に使用するのは非常に困難です問題の根本は CとC++がプログラマがミスを犯さないようにする手助けをしていないことですそのためたとえばメモリの一部が解放された後に誤って使ってしまったりバッファの境界を越えてアクセスしてしまうのを止めるものは何もありません

ここで朗報です Swift 6.2では Spanと呼ばれる新しい安全なポインタ型が導入されていますこれはポインタの利点を提供しながら自動的にこれらのミスを防ぎます Spanはポインタのように機能しますが安全性が組み込まれています Swiftは安全でないことを実行できないようにしてくれますまたメモリを変更する必要がある場合は MutableSpanもあります Spanの詳細については「Improved memory usage and performance with Swift」をご覧ください SwiftがCとC++のポインタを安全でないポインタとしてではなく Spanとしてインポートできたら素晴らしいことです

残念ながらコンパイラはそれを安全に行うための 2つの重要な情報を欠いていますポインタの境界に関する C++からの情報がなければ Swiftは範囲外アクセスを防ぐことができませんまたポインタの有効期間に関する C++からの情報がなければ Swiftはポインタが解放された後の使用を防ぐことができません重要な考え方としてプログラマがその欠けている情報を提供する場合 Swiftは安全でないポインタを SwiftのSpanとして扱うことができます

Swift 6.2では CとC++のコードに注釈を追加することで不足している情報をコンパイラに提供できますそのコードの動作が変わることはありませんただその仮定を明示的にするだけですこれにより Swiftはポインタを使用する CとC++コードに対して安全な呼び出しを行えますポインタを取ったり返したりする関数に注釈を付ける方法を説明しますそのためにアプリに戻りましょう

最初の警告は生のポインタを取得する invertImage関数の使用に関するものです

このようなポインタをパラメータとして取得する関数を安全に呼び出す方法を紹介します

前述したように生のポインタは境界情報が欠落しているため境界内でアクセスしているかどうかを検証する方法がありません注意深く使用しないと範囲外のメモリエラーが発生する可能性がありますこれはその一例です InvertImage関数が Swiftから呼び出されますこの関数は画像への生ポインタである imageポインタを取得しサイズは別のパラメータを持ちます

しかし imageポインタは単なる生のポインタなので誤って大きすぎるサイズを渡してしまうことを止めるものは何もありませんもしそうすれば関数はバッファの境界を越えて読み書きすることになりますこれこそがSpanが解決する問題の1つです invertImageがSpanを受け取るSwift関数としてインポートされたと想像してくださいそうすれば生のポインタとサイズを別々に渡す代わりに直接Spanを渡せますそうすることで間違ったサイズを渡すなどのミスから自動的に保護されます Spanは常にそれらが指すメモリの正しい境界情報を運ぶからです次に水面下でコンパイラが Spanのアンラップを行い正しいポインタとサイズを抽出して C関数に渡しますそうすればミスの余地はありません

コンパイラはこれを実行できますが生のポインタとサイズの間の接続が欠けています invertImage関数はポインタが imageSize要素のバッファを参照していると仮定していますがそれは暗黙の仮定にすぎませんこの関係を明示的に表現して人間とコンパイラの双方が理解できるようにする必要がありますこれはcounted_by注釈で表現できますこの注釈はポインタが指すメモリ内の要素の数をコンパイラに知らせます次に有効期間情報が欠落しているのでポインタはnoescapeという別の注釈も必要となりますしかし今のところは無視して大丈夫ですこれについては後で説明しますこの追加情報を提供すると Spanを直接渡すことで Swiftから関数を安全に呼び出すことができますその後コンパイラが自動的に残りの処理を行いますこの方法ではミスは起こりえません invertImage関数に戻ります

invertImage関数にcounted_by注釈と noescape注釈を追加します

装飾に移動して同じ注釈を追加します

その後 Swiftの呼び出し箇所に戻ります

次に使用されたimageDataを直接渡して Swiftから関数を呼び出します

これで安全でないポインタが関与しなくなったため警告はなくなりました

次の警告は applyGrayScale関数に関するものですこの関数が安全でないC++の型を使用していることを示しています

その関数のC++の定義を見てみましょう名前からわかるように applyGrayScaleは入力画像にグレースケール効果を適用する関数ですこの関数は画像のビューを取得しますがこれはC++のSpan型であることがわかりますここまでは SwiftのSpanの話をしてきましたしかし C++にもSpanの概念があります SwiftがC++のSpanを安全でないとみなすため両者は同じ問題を解決しようとしているにもかかわらず警告が表示されます SwiftのSpanと同様に C++のSpanは誰かが所有する連続メモリにアクセスするために使われる標準的な型ですそれらにはそのメモリとそのサイズへのポインタが含まれています C++のSpanはサイズを知っているため SwiftのSpanと同様に範囲外アクセスを安全にチェックできますただし SwiftのSpanとは異なり C++のSpanには有効期間情報がないため割り当てられたメモリへのアクセスを防ぐことはできませんそのため C++のSpanを使用すると解放後の使用バグが発生することがあります

これはその一例です ApplyGrayScale関数が Swiftによって作成された配列を指すImageView というC++のSpanを取得するとします

applyGrayscaleの内部で他の C++コードが後でそれを使用できるようにおそらくcachedViewのようなグローバル変数にそのポインタを格納するかもしれません

しかしここに問題があります関数が返された後 Swiftは他で使用されていないと仮定して配列を解放するかもしれません今 C++のコードはもはや有効なメモリを指していないポインタを保持していますこれはぶら下がりポインタでありこのポインタへのアクセスは典型的な解放後の使用バグです

一方 SwiftのSpanは安全ですポインタが指すメモリより長く存続することはできません関数がSwiftのSpanを取得する場合関数内でのみ使用できます後で使用するためにcachedViewに保存するなど保持することは許可されません関数が終了した後にポインタが保持される場合その動作はエスケープと呼ばれますコンパイラは Spanがそのスコープをエスケープしようとするたびにこのようなエラーを報告します

このようにぶら下がりポインタは SwiftのSpanでは不可能であり設計上解放後の使用バグは回避されます

C++のSpanは同じような保証を提供しません安全に使うにはぶら下がりポインタを回避するために imageViewパラメータを保持しないように関数を手動で監査する必要があります

パラメータがC++関数をエスケープしないことを確認したら関数定義でその情報を思い出す必要がありますこうすることで人間とコンパイラの両方が関数の動作を理解できるようになります noescape注釈を追加するとそれを行うのに役立ちます noescape注釈は生のポインタと参照にも適用できます

Swift 6.2以降 noescape注釈を持つC++のSpanパラメータは SwiftのSpanとして扱うことができますこれはSwiftのSpanを直接applyGrayscaleに渡せるようになったことを意味しますこれは非常に便利で安全でない定型コードが不要になります C++関数の呼び出しがこれほど安全で簡単であるのは驚くべきことです

applyGrayscaleの定義に移動して

imageViewパラメータに noescapeを追加し

装飾にもnoescapeを追加します

次に Swiftのコアサイトに戻ります

これで保存されていない可変バッファポインタへの一時的なアクセスを削除し imageDataから取得したSwiftのSpanを直接渡すことができます

これで安全にapplyGrayscaleを呼び出せるので警告はなくなりました

次の警告はscanImageRowの使用に関するものでこれはC++のSpanを受け取り別のC++のSpanを返します

では C++のSpanのようなポインタを返す関数を安全に呼び出すにはどうすればよいのでしょうか？

C++のSpanを返すのは危険な場合があります指されているメモリがまだ有効かどうか追跡できないためですこれはその一例です ScanImageRowはimageViewを C++のSpanとして取得し imageDataの選択された行を指す別のC++のSpanを返します関数が返されるとデータの割り当てが解除されますしかし返されたC++のSpanはまだそのメモリを指しておりそれはぶら下がりポインタですアクセスすると解放後の使用となります戻り値をC++のSpanではなく SwiftのSpanのように扱えるのであればこのバグは起こりえないでしょうこれはコンパイラが返されたメモリがまだ有効であり安全に使えるとわかっていない限り SwiftのSpanを返すことさえさせてくれないからですでは返されたSpanを実際に使用しても安全なのはいつでしょうか？ imageViewパラメータと同じメモリの一部を指していますつまり imageViewが存続する間だけ存続します

この関係はlifetimeboundと呼ばれます

それはまさに返されたC++のSpanを SwiftのSpanとしてインポートするために Swiftが必要とする欠けている情報ですそれをlifetimebound注釈で表現することができますこれでコンパイラを安全に使用できるようになります

scanImageRowの定義に移動して

scanImageRow関数の imageViewパラメータに lifetimebound注釈を追加します

装飾も同じようにします

lifetimebound注釈を使用して関数はSwiftのSpanを取得し別のSwiftのSpanを返すことができます Swiftのコア側に移動します

ここで安全でないポインタアクセスを削除し SwiftのSpanを直接渡すことができます

この関数は安全でないポインタではなく SwiftのSpanを返すようになりました再ビルドすると警告は消えます

CとC++のコードを呼び出す際の安全性の低さに対処したので警告はすべて消えましたここまでは CとC++のポインタをSwiftの Spanのように扱う方法について説明しましたしかし Swiftに直接インポートし注釈で安全に使用することができる C++の他の慣用的な型がいくつかありますこれらはカスタムビュー型および参照カウント型ですまずカスタムC++のビュー型を安全にインポートする方法を見ていきますビュー型は所有していないメモリへのポインタや参照を含む構造体ですつまり SwiftのSpanもビュー型です

それでは SwiftのSpanを本当に安全にしているものを詳しく見てみましょう水面下では Spanは特別な種類のSwift型であるエスケープ不可としてマークされていますエスケープ不可の型はコピーを作成することなく別の型のメモリへのビューを提供する型を実装するためによく使用されます Spanの場合と同様に Swiftはすべてのエスケープ不可の型が現在のコンテキストをエスケープしないようにしますこれにより指し示すメモリよりも長く存続しないことを保証するので解放後の使用バグから保護されます C++のビュー型は Swiftでエスケープ不可として安全にインポートできます必要なのは注釈を追加することだけです

これはその一例です私のアプリにはカスタムC++構造体 ImageViewがあり画像の幅と高さ画像のピクセルデータへのポインタを格納しています imageViewはそのピクセルデータを所有していませんそれは別のオブジェクトに属しておりそのオブジェクトは不要になったときにメモリを解放する役割を担っています

つまり imageViewがエスケープするのは安全ではありませんもしエスケープするとビューはそのメモリが解放された後にそのメモリを使用する可能性があります

そのため型が決してエスケープしないようにする必要がありますそのために SWIFT_NONESCAPABLE 注釈を追加できますこのようにしてコンパイラはC++の型をエスケープ不可としてインポートします経験則として構造体に所有していないメモリへのビューやポインタが含まれる場合はこの注釈を使用する必要があります

ビュー型だけでなく C++や他の多くの言語でも型が参照先のメモリを所有し参照カウントによってその参照を追跡することは非常に一般的なイディオムです Swiftには注釈を使用してこれらの型を安全にインポートする機能がありますたとえば C++の画像バッファ構造体は基になるimageDataを所有しています構造体の割り当てが解除されると imageDataも割り当て解除されます画像バッファがSwiftの参照カウント型としてインポートされるようにしたいのでコンパイラは自動的にその有効期間を管理できますそのために SWIFT_SHARED_ REFERENCE注釈を使って Swiftが参照カウントをインクリメントしデクリメントするのに呼び出すべき関数をコンパイラに伝えますこれでSwiftは画像バッファを参照カウント型と見なします

しかし画像バッファを安全に返すためにコンパイラが必要とする情報がもっとあります

C++関数が画像バッファを返すとき 2つの状況が考えられます第一に関数が新しく作成された画像を返す場合それが終了したときに画像を解放するのは呼び出し元の責任ですこの場合はメソッドにSWIFT_ RETURNS_RETAINED注釈を付けますこれは画像が使用されなくなったときに呼び出し元で画像を解放するように Swiftコンパイラに指示します第二に関数がすでに存在する画像への参照を返す場合画像を保持したいのであれば画像を保持するのは呼び出し側の責任ですこの場合はメソッドにSWIFT_ RETURNS_UNRETAINED注釈を付けますこれにより画像を保持したい場合に Swiftコンパイラに対して画像を保持する必要があることを伝えますこれらの注釈を追加すると所有権の期待が明示されるので Swiftはメモリを安全に管理できます

欠落している情報を提供するためにコードに注釈を付けることで SwiftはCとC++の関数と型を安全に使用できますこれらの注釈によってコードの動作が変更されることはありませんコード内の仮定を明示的にするだけです

これまで取り上げた注釈とその使い方をまとめましょう

関数パラメータや戻り値がポインタやarray型でありそれが1つ以上の要素のメモリを指している場合は counted_by注釈を使用して要素の数を示します他が所有するメモリをパラメータが参照しそのパラメータが関数をエスケープしない場合は noescapeを使用します

関数の返り値がメモリを参照しそのメモリの有効期間がパラメータの有効期間に依存する場合は lifetimebound注釈を追加しますこの情報を追加することで使用するために呼び出し箇所で式を必要としない安全なSwiftのSpan型として Swiftがポインタをインポートできるようにします

また SwiftがカスタムC++の型を安全に管理するための注釈を追加することもできます C++の型がビューポインタまたは所有していないメモリへの参照を格納する場合はSWIFT_ NONESCAPABLEを使用してくださいこれによりコンパイラは型をエスケープ不可の型としてインポートします

代わりに型が参照カウントされている場合は SWIFT_SHARED_REFERENCEを使用しますその後コンパイラはメモリを自動的に管理します

たくさんありましたねビデオを一時停止して休憩するなら今がそのタイミングです必ず戻って来てくださいね次は CとC++のコードをより安全に扱うためのとてもエキサイティングな新しいツールを紹介します

それでは CとC++のコードをどのように安全にできるかについてお話ししますアプリでは SwiftがCとC++を安全に呼び出せるように注釈を追加しましたただし純粋なCとC++のコードはまだ安全ではありません一歩間違えば簡単にセキュリティバグが発生します理想を言えばそのコードをSwiftで書き直して完全な安全性を確保したいですしかしそれは現実的ではないこともあります CとC++をSwiftのように安全にすることは不可能ですが CとC++で部分的な安全を提供するツールをいくつか紹介しますまず C++の境界の安全性を強化するために開発したツールについて説明します

なぜC++はまだ境界の安全性がないのか疑問に思われるかもしれません先ほど話したように Spanはすでに境界情報を格納していますただしこのような Spanの配列の添え字に対して C++ではデフォルトで境界が検査されないことが問題ですまたベクターなどの他の標準コンテナについても同じことが言えます Xcodeには C++ Standard Library Hardeningと呼ばれる機能がありますこれは標準的なC++のビューとコンテナの配列の添え字に境界検査があることを確認しますまた標準ライブラリに他のいくつかの安全性チェックも追加されます

C++ Standard Library Hardeningを有効にした後でもまだ別の問題があります

境界情報を持たないため境界検査ができない生のポインタを使用することはできますしたがって C++を使用する最善の方法は生のポインタを避け C++のSpanのような標準型を使うことです

これを支援するために Xcodeでは C++で安全でないポインタを使用したときのエラーをオンにできますこれによりコードを確認し必要に応じて生のポインタをC++のSpanや標準コンテナに置き換えることができます

注意点としてこれらのエラーは境界の安全性に関するもので有効期間に関するものではありません

C++プロジェクトの境界を安全に保つにはプロジェクトのビルド設定でをに設定しますこれにより C++Standard Library Hardeningが有効になり安全でないバッファの使用エラーもすべて解消されます

Cはどうでしょうか？ C++とは異なり Cにはポインタに境界情報を持たせるための Spanのような標準型がありませんそこで C向けに境界の安全性を保証する新しい言語拡張機能を開発しましたこれはXcodeで使えるようになりましたこの言語拡張機能を有効にするとコンパイラは Cコード全体で境界情報が欠落している箇所を教えてくれます次に境界の注釈を追加して不足している情報を表現できますこの例ではバッファに counted_by注釈を追加できますこの注釈は以前に安全なSwiftとCの相互運用のために使用されたものと同じです

そうするとコンパイラは境界外のメモリアクセスを安全に把握する境界検査を実行時に挿入します

Xcodeのプロジェクト設定ですべてのCファイルに対して境界の安全性の拡張機能を有効にできます詳しくは llvm.org Webサイトの境界の安全性に関するドキュメントをご覧ください

このセッションでは Swiftの安全性を確保し CやC++のコードを安全に呼び出す方法について説明しました CとC++をSwiftのように安全にすることは不可能ですがより安全にすることはできます

ここでは C C++ Swiftを混在させるときに最高の安全性を得るためのヒントをいくつか紹介します

SwiftでStrict Memory Safetyをオンにしますこれは安全でないコンストラクタを使用するたびに警告し CとC++のAPIの安全でない使用を見つけるのに役立ちます注釈を追加することで Swiftが安全でないCとC++のAPIを安全に操作できることを確認します

CとC++をデフォルトでより安全にしますこれを行うには CとC++の新しい境界の安全性機能を有効にします

私たちはオープンソースコミュニティと協力して C C++ Swiftをシームレスかつ安全に連携させることを目指しています皆さんのご参加とフィードバックは私たちにとって非常に重要です

ぜひお試しいただき意見をお聞かせくださいご視聴ありがとうございました

3:19 - Unsafety can be subtle

// Swift
var imageData = [UInt8](repeating: 0, count: imageDataSize)
filterImage(&imageData, imageData.count)

4:01 - Strict memory safety

// Swift
var imageData = [UInt8](repeating: 0, count: imageDataSize)
filterImage(&imageData, imageData.count)
//warning: Expression uses unsafe constructs but is not marked with 'unsafe'

8:00 - Raw pointers don't prevent out-of-bounds errors
```
// C/C++
void invertImage(uint8_t *imagePtr, size_t imageSize);
```

8:21 - Raw pointers don't prevent out-of-bounds errors

// Swift
var imageData = [UInt8](repeating: 0, count: imageSize)
invertImage(&imageData, imageSize)

8:30 - Raw pointers don't prevent out-of-bounds errors

// Swift
var imageData = [UInt8](repeating: 0, count: imageSize)
invertImage(&imageData, 1000000000000)

8:48 - Solution for out-of-bounds error

// Swift
func invertImage(_ imagePtr : inout MutableSpan<UInt8>)

8:54 - Solution for out-of-bounds error

// Swift
var imageDataSpan = imageData.mutableSpan
invertImage(&imageDataSpan)

9:58 - Express bounds information using __counted_by

// C/C++
void invertImage(uint8_t *__counted_by(imageSize) imagePtr __noescape, size_t imageSize);

12:10 - Unsafe function declaration taking a C++ span

// C++
using CxxSpanOfByte = std::span<uint8_t>;
void applyGrayscale(CxxSpanOfByte imageView);

13:21 - Unsafe C++ function caching a C++ span

// C++
CxxSpanOfByte cachedView;
void applyGrayscale(CxxSpanOfByte imageView) {
  cachedView = imageView;
  // Apply effect on image ...
}

14:08 - Swift Span prevents escaping scope

// Swift
var cachedView: MutableSpan<UInt8>?
func applyGrayscale(_ imageView: inout MutableSpan<UInt8>) {
  cachedView = imageView // error: lifetime dependent value escapes its scope
  // Apply effect on image ...
}

15:18 - Express lifetime information using __noescape

// C++
CxxSpanOfByte cachedView;
void applyGrayscale(CxxSpanOfByte imageView __noescape) {
  // Apply effect on image ...
}

15:56 - Safely use a C++ Span as a Swift Span

// Swift
var imageDataSpan = &imageData.mutableSpan
applyGrayscale(&imageDataSpan)

17:21 - Returned C++ Span is unsafe

// C++
CxxSpanOfByte scanImageRow(CxxSpanOfByte imageView,
                           size_t width, size_t rowIndex);

18:06 - Swift Spans prevent use-after-free by design

// Swift
func scanImageRow(_ imageView : inout MutableSpan<UInt8>,
                  _ width : Int, _ rowIndex : Int) -> MutableSpan<UInt8>
// error: a function with a ~Escapable result requires '@lifetime(...)'

18:47 - Express lifetime dependency with __lifetimebound

// C++
CxxSpanOfByte scanImageRow(CxxSpanOfByte imageView __lifetimebound,
                           size_t width, size_t rowIndex);

18:50 - Safely return a C++ Span as a Swift Span

// Swift
var imageDataSpan = imageData.mutableSpan
var rowView = scanImageRow(&imageDataSpan, width, y)

22:29 - Import a C++ view type as SWIFT_NONESCAPABLE

// C++
struct ImageView {
  std::span<uint8_t> pixelBytes;
  int width;
  int height;
} SWIFT_NONESCAPABLE;

23:31 - Import a C++ reference-counted type

// C++
struct ImageBuffer {
  std::vector<uint8_t> data;
  int width;
  int height;
  std::atomic<unsigned> refCount;
} SWIFT_SHARED_REFERENCE(retain_image_buffer, release_image_buffer);

void retain_image_buffer(ImageBuffer *_Nonnull buf);
void release_image_buffer(ImageBuffer *_Nonnull buf);

23:57 - Safely return a reference-counted type

// C++
ImageBuffer *_Nonnull createImage() SWIFT_RETURNS_RETAINED;
ImageBuffer *_Nonnull getCachedImage() SWIFT_RETURNS_UNRETAINED;

27:51 - C++ standard library hardening

// C++
void fill_array_with_indices(std::span<uint8_t> buffer) {
  for (size_t i = 0; i < buffer.size(); ++i) {
    buffer[i] = i;
  }
}

28:59 - C++ unsafe buffer usage errors

// C++
void fill_array_with_indices(uint8_t *buffer, size_t count) {
  for (size_t i = 0; i < count; ++i) {
    buffer[i] = i; // error: unsafe buffer access
  }
}

30:11 - Bounds safety extension for C

// C
void fill_array_with_indices(uint8_t *__counted_by(count) buf, size_t count) {
  for (size_t i = 0; i < count; ++i) {
    buf[i] = i;
  }
}

C、C++、Swiftを安全に併用する方法

関連する章

リソース

関連ビデオ

WWDC25