文字列で表記された式の値を求めるRVAL関数のver.2.0ができました。 RVAL(”2+3*4”)とすれば演算優先順位通りに計算してその結果を得ることができます。 なお、プチコン3号のすべての演算子、関数が使用可能です。(公開キーと解説はコメントにて)

例えばA=RVAL("2+3*4")でAには2+3*4を計算した14という値が入ります。 A=RVAL("SIN(RAD(30))")でAには0.5という値が入ります。 もちろん、関数には自作関数も使用可能なので便利な関数を作れば計算がすごく楽になります。 私が以前作った「簡易関数電卓QSP」用の拡張関数ライブラリも戻り値があるもの（RETURN 0になってないもの）はそのままで使用可能です。

RVAL関数を使えばこのようにたったの1行で超簡易関数電卓を作れます。 　@L:LINPUT A$:?RVAL(A$):GOTO@L 8*8*PI()と入力すれば半径8の円の面積を求められます。 ちなみにRVAL関数と合わせても余裕でQSPに収まるコンパクトサイズです。（RVAL関数を内包している「簡易関数電卓QSP」もコア部分をこのver.2.0にすることで大幅なリスト短縮が可能）

なお、プログラムスロット1は実行用に使用しているためこのRVAL関数はプログラムスロット1以外で実行してください。 公開キー【 D4E1E73 】、ファイル名「RVAL」です。

原理はすごく単純で入力した式を別のプログラムスロットで実行してその値を戻しているだけです。 そのためプチコン3号で実際に実行できるすべての式が構文解析不要でその値を取得できます。 このRVAL ver.2.0がver.1.0と比べて改善されたのは次の4点です。 (1)プログラムリストの大幅な短縮 (2)占有プログラムスロットを2つから1つへと減らした (3)STR$の都合で有効桁数が6桁しか無かったのが15～16桁（プチコン3号の実数型の仕様）になった。 ただし、全桁表示するにはFORMAT$を上手く使うか、簡単に行いたいならば私の自作関数のPSTR$を使用する必要がある。。 (4)プチコン3号で実行できない式の値を求めようとしてエラーが出た際に次に実行するためにプログラムスロット1の内容を削除しなければならないのだけどその処理を自動で行うようにした。

うえこうさんへ プログラムの動作中に別スロットでプログラム実行するというのは様々なプログラムに応用できると思います。 VAR("1:A")でプログラムスロット1の変数Aが取得可能になるのですが、事前にUSE 1を実行してさらにGOSUBで実行してグローバル変数を有効化（実体化）させる必要があります。

RVAL関数ver.1.0は即興で作ったものであまり出来が良いものではなかったのですが、簡易関数電卓QSPではそのver.1.0をそのまま実装しています。 しかし、簡易関数電卓QSPを作った後にRVAL関数を見直してみたところ大幅に短縮が可能であることが分かったのでこの度ver.2.0という形で公開しました。

セキュリティーが。 コマンドインジェクションが。

れいさんへ プチコン3号ではそのようなことを考える必要はありません。 不正なプログラムを実行させてシステムにダメージを与えたり情報を漏洩させたりすることはできないような仕様になっています。 もしも、プチコン3号がセーブ時にダイアログが出ない仕様になったら自作プログラムに暗号化（難読化）したコードを潜ませておいてプチコンのセーブデータを破壊しまくることも可能なのですが。

自前で式評価しようと、再帰下降型の式コンパイラとインタプリタ書いたら 800行くらいになって頭抱えてます。(Cでのプロトタイプ) プチプチ打つ気力もないし、互換性も低い。

言葉が悪いのをご容赦頂くとして、少々短絡的ではないでしょうか。 先のれいさんの発言は、「関数の目的以外のことを、ユーザの悪意で可能で有る」ことを問題点として示唆されている訳で。 不要なコードを実行できてしまうのが問題であり、実行後を前提とした回答は、答えになっていないかと。 簡単に対策出来るとはいえ、ダイアログ地獄でも初心者には驚異と言えるでしょうから「実装者の意図しないプログラムの実行を可能」とする実装には慎重になった方が良いのは、と。 例えば「実行する演算子や関数の制限対応」か、制限をかけないのであれば「充分な危険性の周知」が必要かもしれません。 非常に強力なコードの後に、思考停止とも取れる発言を伺ったので老婆心と思いながら書き込ませて頂きました。 長文、乱文失礼しました。

みき★さんへ 私も昔ポケコンのBASICでC言語のインタープリタを作りましたが、自前で式評価を実装するのは結構大変ですよね。（ちなみにポケコンPC-E500では動作中のプログラムの自己書き換えも可能だった） それくらいの行数になるのは仕方がないと思います。 私がRVAL関数を作ったのはEVAL関数みたいな式の評価を行う関数を作りたかったけどまともに作るのが面倒だし、OSP（1画面プログラム）やQSP（WIDTH 16の1画面プログラム）でも活用できるくらいの小さいサイズにしたかったというのが発端です。 少し考えて「別スロットで実行させれば簡単に実現できるのでは？」と思い即興で作ってすぐに公開したのがRVAL関数のver.1.0です。 その代わり急いで公開したためリストにミスが多く機会を見て作り直そうと思っていて今回ようやくver.2.0を公開することができました。

ishさんへ 個人的にはRVAL関数は現状の仕様で全く問題ないと思います。 「任意のコードが実行可能」と書くと危険な感じがしますが、それはプチコン3号の仕様を考えると極めて当然であるためです。 もしも、RVAL関数そのものに危険な部分があるとすれば「ソースコード操作命令を使って別スロットへプログラムを書き込み」「GOSUBで別スロットのプログラムを実行」という2点になると思います。 それらはマニュアルにも記載されてないような特殊なことを行っているわけではなくバグを突いた悪質なものでもなくマニュアルに普通に掲載されているプチコン3号の仕様の範囲で作っています。 （続く）

そこでまずはGOSUBの方から見ていけば「GOSUBで呼ばれたサブルーチン内で任意のコードが実行可能」というのは当たり前のことだと思います。（ここでの「任意のコード」はバグを突いてシステムを強制終了させるようなコードだけではなくダイアログ地獄などのいたずらプログラムも含む） もしも、これが危険であるならばGOSUB命令そのものを廃止するしかないでしょう。 それに危険な自作関数が作れてしまうDEFも廃止すべきとなります。 個人的にはGOSUB命令やDEF命令には全く問題がないと思うのですがishさんはどう考えておられるのでしょうか。 （続く）

命令が問題ではなく実際に作ったプログラムでそのようなことが可能であることが問題であるならば、プチコン3号でお絵かきソフトを作っている人に対して「貴方が作っているお絵かきソフトは任意の絵が描けるため描ける絵に制限を加えるか著作権侵害が可能であるという危険なプログラムであることを周知徹底させてください」と言っているようなものです。 私はこれは非常に馬鹿げたことだと思います。 それは、お絵かきプログラムに問題があるわけではなく著作権侵害をする側に問題があるためです。 それなのに「（結果は関係なく）著作権侵害が可能なことが問題なんだ」という人を見たらどう思いますか？ ただし、著作権に関しては議論すると面倒な部分が多いためあまりこの話題はここで深く掘り下げるつもりはありません。 （続く）

PCの開発環境におけるEVAL関数とこのRVAL関数は似ているようで全く異なります。 それがれいさんへ宛てたレスの部分でこの前提があるからこそ「危険ではない」と個人的には思います。 このRVAL関数が危険ならば他人が作ったものプログラムは自分でリストをすべて読み内容を熟知しているものを除きどれも危険になってしまいます。（どんなコードが含まれているかが分からないため） もしも、「危険度」を示すならばそれくらいの危険度ですね。 （続く）

過去に私が作った自作関数においては変数の型判別を行うSUFFIX関数においてはver.3.1.0から「文字列と数値との比較演算で3を返すようになった」という本来の仕様の範囲外のことを利用して行っているため「将来のバージョンアップで正常動作しなくなる可能性はある」という危険性はちゃんと書いておく必要性はあるかなと感じています。（RVAL関数ではVARで別スロットの変数を読み出しているのはマニュアルの範囲外のことなので、もしもRVALの危険性を書くとすればこの部分だけになると思う） また、QSPなどのリスト短縮に特化しているものも現行バージョンの仕様の隙を付いて可能な限りのリスト短縮を行っているので将来のバージョンアップで動作しなくなる可能性は否定できないのですがこれは自作関数とは違って周知徹底をするまでもないと考えています。（現行のバージョンで動作すればOKみたいな感じ） （続く）

何が「危険」と感じるのは人それぞれであり、「自分はこれが危険であると思った」と思うのは自由であり、自分が作るプログラムはそのようなことがないような配慮をするのは全く問題ないのですが、他人に自分のやり方、考え方を強要するような行為は個人的には「何だかなぁ」と思う次第であります。（「アドバイス」と感じられるような書き方ではありませんでしたので） 私は（例えばQSPを見て「短く書いても意味がないので可読性を重視すべき」など）「自分はこれが良い」と思って行っていることを「見当違いの意見」で否定されるのは嫌いなのでレスが長文になったことをお許しください。 「計算式が間違っている」とか「正常に動作していない」とかいう私が正しくない部分の指摘ならば逆に喜びますのでどんどんおっしゃってください。 （終わり）

【　重　要　】 ～～　初心者の方へ　～～～ ここまで読んだ初心者の人がRVAL関数は危険だから使うのをやめておこうと変な誤解を招いてしまう恐れがあるため最後に正しいことを書いておきます。 RVAL関数は単にGOSUB経由で別スロットの計算式や自作関数を実行が可能になるだけの関数であり、この関数そのものには危険な部分は全くありません。 危険なプログラム（システム破壊みたいなものではなくいたずらプログラムみたいなもの）も実行可能ですが、それはRVAL関数を使わなくても普通に書くことが可能であり、RVAL関数に問題があるわけでは全くありません。（どのプログラムにも危険な部分がある可能性がある） RVAL関数の便利さは使ってもらわないと分からないと思います。 それくらい便利な関数です。（プチコン3号に標準で実装してもらいたいレベル）

うーん。 俗に言うEVAL系の関数、つまり「使用者が入力した文字列を、命令文と解釈する関数」が危険だと言われるのは、 「悪意ある使用者が、EVAL関数を使用する事で任意の命令を実行させる事が出来る」 事だと思うのですが、違うのでしょうか？ 仮に、この理由で今回作成されたRVAL関数は危険だ、という主張であるならば、それは的外れだと自分も思うのですが。 何故なら、そもそもプチコンはいちいちEVAL系の関数を使用しなくても、自分で自由にコードを実行出来るわけですし。 （RVAL関数はあってもなくても関係ない）

あ、ちょっと自分でも無いかな、とは思うのですが…… 「プチコンで、使用者の入力文字列をそのまま命令文として扱うのが楽だと知ったから、他のプラットホームでもそれを実装する」 とやらかしちゃう危険性はある、のかなぁ。 例えば、WEBアプリケーションにおいて「使用者の入力した式をそのまま解釈させたい」なんて思ってEVAL系を実装すると、そこは普通にセキュリティホールになりえちゃうから要注意。

ご返答ありがとうございます。 議論は苦手ですが、すこし書きます。 まず「任意コードの実行」自体には問題視していません。 繰り返しますが「関数の目的以外のことを、ユーザの悪意で可能で有る」を事を問題視しています。 説明して頂いた所で当てはめると「危険なプログラムの実行」あたりかと。 長く書いていただいて大変恐縮ですが、技術的、関数自体は当初から一切問題視していません。 論点としては「関数の使われ方」です。 具体的なケースですと、RVAL関数を使用し関数電卓を作ったとして、任意でユーザが値を入れられる状態ではどうでしょうか。安全でしょうか。 もし私が注意喚起をするならば「当該関数に、想定外の値を渡らないように実装してください。」でしょうか。 これを「プチコン３号では考える必要はありません。」との帰結は流石に違うかなぁと。違和感を感じます。

文章を推敲していたら、ケインさんが要点を纏めてくださった件についてorz れいさんの「セキュリティーがー　コマンドインジェクションがー」を「変なコードが実行できる状態って、そもそも駄目なんじゃね？」と、私が勝手に判断してるのも問題ではあるのですが。 おちゃめさんの「変なコード書いても、大丈夫。考える必要ないよ」　という返しは、それはちょっと言い過ぎというか、答えになっていないよ、と。 まずは「変なコードが実行できる状態だから、正しく使おうね」「そもそも、変なコードを実行できない状態を保とうね」と啓蒙するか、「変なコード来ても実行させないよ」という状態にしないと答えにならないのでは、と。

あれ、何か誤解されていそうなので補足。 関数電卓でこのRVALを実装して、それにユーザーが任意の値を入れられたとして、なんら危険な事はないと思うのですが…… そもそもish さんのいう「危険な状態」とはどういった状態なのでしょうか？ 仮に「関数電卓が想定外の動作をする」事を「危険な状態」と定義するのであれば、それは違うのではないか、と思うのですが。 EVAL系における「危険」とは、「本来であれば出来ない事であるにも関わらず、ユーザーがそれを実行出来てしまう事」だと思うのですが。

「危険な状態」というか、「関数の目的以外のことを、ユーザの悪意で可能で有る」状態という事で。 初心者が多いと思われるプチコンなので、製造者が意図しないコードが実行できる状態はあまり良くないだろう、と。説明が足りず済みません。 ユーザが問題のあるコードを走らせなきゃいい訳ですし、自己責任の範疇だと思いますが。初心者に「自己責任で判断」というのも厳しいかと。 例えば、こんなシナリオとか。 製造者「関数電卓作ったよ」 ↓ 悪意のユーザ「こんなコード走らすとおもしろいよ（実際は永久ループ）」 ↓ 普通のユーザ「よくわからないけど、動かなくなった！」 無理やり感はありますが「本来、初心者は知り得ない、出来ない事にもかかわらず、ユーザが、それを実行できてしまう」と、そんな感じです。

うーん。 悪意の向け先、と言う前提条件から違ってるのかな。 EVALの場合、悪意はソフトを実行しているPCに向けられます。 それと異なり、今回は第三者に向かう事を気になされているようですが…… それはなんと言うか、RVALの問題じゃないんじゃ…… (RVALがなくても、悪いコードは教えられますよね？)

論点がズレかかっていますから戻すと。 くどいですが、強力な関数なので、使い方、使われ方を考えないといけないよ。毒にも薬にもなるよ。「(RVALがなくても、悪いコードは教えられますよね？)」が正にそれで、決して「プチコン３号では考える必要はありません。」で片付ける問題じゃないよ、と。 RVAL関数は「悪意があれば永久ループもするし、ダイアログがでるけどファイルも削除できちゃうよ」って事が、使うユーザにも、関数の使用者にも伝わっていれば問題はないとおもうわけで。このような性質の関数は他に無いから「充分な危険性の周知」として伝える必要があるのでは、と。 そうじゃなければ、「実行する演算子や関数の制限対応」をして、出来る事を制限する必要があるのでは、と。

【　重　要　】 ～～　初心者の方へ　～～～ ここまで読んだ初心者の人がRVAL関数は危険だから使うのをやめておこうと変な誤解を招いてしまう恐れがあるため（再び）最後に正しいことを書いておきます。 RVAL関数は単にGOSUB経由で別スロットの計算式や自作関数を実行が可能になるだけの関数であり、この関数そのものには危険な部分は全くありません。 危険なプログラム（システム破壊みたいなものではなくいたずらプログラムみたいなもの）も実行可能ですが、それはRVAL関数を使わなくても普通に書くことが可能であり、RVAL関数に問題があるわけでは全くありません。（どのプログラムにも危険な部分がある可能性がある） RVAL関数の便利さは使ってもらわないと分からないと思います。 それくらい便利な関数です。（プチコン3号に標準で実装してもらいたいレベル）

その関数を二次利用していいですか?

このRVAL()関数は自由にプログラムに組み込んで使って貰って構いませんよ

ありがとうございます！

RVAL関数がver.2.1に更新しているのでこちらのトピックスをご覧になってください。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0fZKWc_BQ

はい。 ではそちらの方を使わせて頂きます。