> - vload_getがシステムエラーを出す原因として考えられることはなんでしょうか?
エラー -1 はHSP内のエラーでHSPERR_UNKNOWN_CODEですが、これは下記の2ケースで発生します。
〇HSPのコード内での明示的なエラー
※今はcode_get()内での単一の項目の評価時にのみ発生させるコードがないです。
そしてそれが発生するのは大きく分けて、コードジェネレータ(hspcmp)のバグが、何らかの理由でメモリ的にバイトコードが壊れているか、の2択ですかね。
前者はあまり考えられませんが、後者も結構ピンポイントでメモリアクセスしないといけないので、あまり現実的ではないですね。
〇HSP以外で発生した例外全て
より正確には、HSP側が知らない例外(つまり、HSP内で発生させてない例外)です。
この種の例外は通常はC++レイヤーで発生しうるものですが、他にOSレイヤー、ハードウェアレイヤーの例外も含まれたり含まれなかったりします。
しかし、低レイヤーの例外はパフォーマンスやセキュリティも関係するため、含まれる・含まれないを決めるのはコンパイラです。
もっと具体的にはコンパイル時の引数で決まったりするものなのですが、今のHSPでどうなってたかはちょっと確認しないと分からないです。
しかしHSPのランタイムEXEのビルドはクローズドなので…。
ちなみに、hsp3.6b1で下記のようにnullアクセスさせてみたら何もいわずにしんだので、少なくともnullアクセスのAccessViolationは補足されてなさそうな雰囲気です。
dupptr a, 0, 16, vartype("int")
a(0) = 10
> - このへんを解析できそうな資料はどこかにありませんでしょうか?
解析できる資料…かどうかは分かりませんが、vload/vsave系が含まれるプラグインはhspdaで、これのソースコードはOpenHSPでいうとplugins/win32/hspdaにあたります。
おそらくコード追うのが一番早いとは思いますが、これはプラグイン形式での提供になり、かつHSP内の変数へのアクセスとなるため、HSP内部に依存した処理が多くコード読むだけでは簡単ではないように見えます。
――――――――――
今回の件だと、どこが悪いかは聞いた報告からだとかなり調査が難しいので、せめて実際に失敗するデータ等がないと非常に厳しいように思います。
あるいは、それも難しいのであればご自分でhspdaやHSPのランタイムをビルドして、デバッグ実行するのが一番早いのではないでしょうか。