[過去ログ] C#, C♯, C#相談室 Part96 (1002レス)
前次1-
抽出解除 必死チェッカー(本家) (べ) 自ID レス栞 あぼーん

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
155: デフォルトの名無しさん (ワッチョイ 1232-IMun) [sage] 2022/03/16(水) 01:45:02.44 ID:lykY2TTP0(1/2) AAS
>>153-154
仰る通りです

ECMA-335の文言"Managed pointers cannot be null"で検索してみたら案の定ツッコミありましたが
外部リンク:github.com
これを受けてか、トップのNullRef<T>()に関する注釈にも
(10) Per ECMA-335, Sec. II.14.4.2, it is not strictly legal for a gcref to point to null.
However, all .NET runtimes allow this and treat it in a type-safe fashion,
including guarding accesses to null gcrefs by throwing NullReferenceException as appropriate.
と書かれていて問題なさそうな見解です
仕様に準拠していないというのは…JITコンパイラ的にどうなのか
言及を忘れていましたが、アセンブリにコード欠落は見受けられないのでC#コンパイラの問題ではないし

AddByteOffset<T>(ref T, IntPtr)にしても関連する注釈は
(1) Arithmetic operations on gcrefs (such as via Unsafe.Add) are not checked for correctness by the runtime.
The resulting gcref may point to invalid memory or to a different object. See ECMA-335, Sec. III.1.5.
のみですし、また前項と合わせてECMA-335が示されていますから、ILと無関係でもないでしょう
System.Runtime.CompilerServices.Unsafe.dllをデコンパイルしてみてもコメントと同じコードが示されます

Framework時代ならSafeBuffer継承とかやってましたが(SafeMemoryMappedViewHandleはコンストラクタがinternalなので)
これもこれで今見たら「SafeBuffer may be unavailable in future releases.」で笑えぬ
157
(1): デフォルトの名無しさん (ワッチョイ 1232-IMun) [sage] 2022/03/16(水) 15:09:58.97 ID:lykY2TTP0(2/2) AAS
>>137
137(2): デフォルトの名無しさん (ワッチョイ a236-8qwV) [sage] 2022/03/15(火) 17:49:18.74 ID:uT8cdwkS0(1/4) AAS
相談させてください。

IntPtr を ref int に変換するために以下のようなコードを書くと、期待通り False と表示されます。

IntPtr ptr = Marshal.AllocCoTaskMem(4);
ref int x = ref Unsafe.AddByteOffset(ref Unsafe.NullRef<int>(), ptr);
Console.WriteLine(Unsafe.IsNullRef(ref x)); // False と表示される
Marshal.FreeCoTaskMem(ptr);

しかし、以下のように意味のない for 文を追加すると、コードの最適化が有効な場合のみ True と表示されます。

for (int i = 0; i < 0; i++) { } // 意味のない for 文
IntPtr ptr = Marshal.AllocCoTaskMem(4);
ref int x = ref Unsafe.AddByteOffset(ref Unsafe.NullRef<int>(), ptr);
Console.WriteLine(Unsafe.IsNullRef(ref x)); // 最適化が有効な場合のみ True と表示される
Marshal.FreeCoTaskMem(ptr);

ただし、意味のない for 文があっても
Unsafe.AddByteOffset(ref Unsafe.NullRef<int>(), ptr)
→ Unsafe.SubtractByteOffset(ref Unsafe.NullRef<int>(), -(nint)ptr)
のように書き換えると常に False と表示されるようになります。

なぜこのようなことが起こるのかさっぱり見当がつかないので、お知恵を拝借できないでしょうか。
私の環境を分かる範囲で書くと以下のとおりですが、他に何か必要な情報があればお教えください。

Windows 10 Pro (21H2)
Microsoft Visual Studio Community 2022 (64 ビット) Version 17.1.1
コンソール アプリケーション、.NET 6.0

どうぞよろしくお願いいたします。
>>153
153(2): デフォルトの名無しさん (ワッチョイ a236-8qwV) [sage] 2022/03/16(水) 00:04:15.38 ID:pAqxvPky0(1/2) AAS
>>151
なるほど…。
ただ、Unsafe.IsNullRef(ref Unsafe.NullRef<int>()) と書けてこれが true を返すので、
値型に対するヌル参照が定められていない場合は Unsafe.NullRef<T> の T に int が
指定できること自体がバグということになってしまうような気もします。
一応未定義ではないけど、CLR 外部との相互利用等で必要に迫られない限り
使ってくれるなという感じなのでしょうか。

>>152
ご親切に説明していただきどうもありがとうございます。
逆アセンブルの結果に “なぜだか理由は分からないが” 0 になっている部分があって、
そこから x が null にされているというという事実が読み取れる、ということですね。
(まだ間違っていたら大変申し訳ありません)

> NullRef<int>が宜しくないのか、それをAddByteOffsetに与えるのがダメなのか
NullRef<T> と AddByteOffset<T> のソースコードのコメントにはそれぞれ

ldc.i4.0
conv.u
ret

ldarg.0
ldarg.1
add
ret

とあって、これを見る限り、NullRef<int>() を AddByteOffset<int> に与えることの問題は
私には読み取れませんでした。
(そもそもこの問題で IL を持ち出すこと自体が見当外れなのでしょうか)
もちろん、実際には特殊な JIT 最適化が行われているのでしょうが、
その結果 IL から期待される動作と変わってしまうようなら、
やはりバグとして報告したほうがよいのかなというのが今のところの考えです。
よくよく調べてみたらズバリそのものが有りました
外部リンク:github.com
>>156
156(1): デフォルトの名無しさん (ワッチョイ 7d02-WCXV) [sage] 2022/03/16(水) 02:59:05.97 ID:b5JRB2Cp0(1/3) AAS
最近の標準ライブラリの実装を見るに、.NET開発チームはIntPtrを使わせたくないように感じる
ポインタ弄るなら、あぶねー事やってんだから明確にunsafe宣言しろって事なんだろうな
で言われている様な主旨のコメントもありますね

元コードの添え書きを見るに意図されたものと見受けられますが
ぬるぽを多少オフセットした所でデリファンレスしたら一緒という事でしょうか

昨年の時点で修正が入っていますが、マイルストーンは7.0.0とされ6.0.3でも取りこまれていません
外部リンク[cpp]:github.com
.NET 7.0 Previewにはマージされており、その後さらに周辺コードはリファクタリングされ移動しています
外部リンク:github.com

まぁやはり本来は相対オフセットが期待されるところですから
絶対オフセットではなく大人しくAsRefを使うべきなのかもしれません
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.042s