[過去ﾛｸﾞ]
C#, C♯, C＃相談室 Part96 (1002ﾚｽ)
C#, C♯, C＃相談室 Part96 http://mevius.5ch.net/test/read.cgi/tech/1639965805/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
153: デフォルトの名無しさん (ﾜｯﾁｮｲ a236-8qwV) [sage] 2022/03/16(水) 00:04:15.38 ID:pAqxvPky0 >>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 から期待される動作と変わってしまうようなら、 やはりバグとして報告したほうがよいのかなというのが今のところの考えです。 http://mevius.5ch.net/test/read.cgi/tech/1639965805/153
155: デフォルトの名無しさん (ﾜｯﾁｮｲ 1232-IMun) [sage] 2022/03/16(水) 01:45:02.44 ID:lykY2TTP0 >>153-154 仰る通りです ECMA-335の文言"Managed pointers cannot be null"で検索してみたら案の定ツッコミありましたが https://github.com/dotnet/runtime/issues/41418#issuecomment-681177889 これを受けてか、トップの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.」で笑えぬ http://mevius.5ch.net/test/read.cgi/tech/1639965805/155
157: デフォルトの名無しさん (ﾜｯﾁｮｲ 1232-IMun) [sage] 2022/03/16(水) 15:09:58.97 ID:lykY2TTP0 >>137>>153 よくよく調べてみたらズバリそのものが有りました https://github.com/dotnet/runtime/issues/61510 >>156で言われている様な主旨のコメントもありますね 元コードの添え書きを見るに意図されたものと見受けられますが ぬるぽを多少オフセットした所でデリファンレスしたら一緒という事でしょうか 昨年の時点で修正が入っていますが、マイルストーンは7.0.0とされ6.0.3でも取りこまれていません https://github.com/dotnet/runtime/blob/v6.0.3/src/coreclr/jit/morph.cpp#L12906-L12918 .NET 7.0 Previewにはマージされており、その後さらに周辺コードはリファクタリングされ移動しています https://github.com/dotnet/runtime/commit/132cc2f2d00e00b7f0dfd43498077da65cc27d29#diff-5b83397bbbdd17bb9457998b520fdaaa474d165390985b66f32371561b6d0bacR13505 まぁやはり本来は相対オフセットが期待されるところですから 絶対オフセットではなく大人しくAsRefを使うべきなのかもしれません http://mevius.5ch.net/test/read.cgi/tech/1639965805/157
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.044s