stuncloud/UWSCR

fgetで存在しない行を取得した場合の戻り値がUWSCと異なる

Closed this issue · 4 comments

概要

タイトルの通り

空文字を返すより存在しないからemptyを返すのほうが論理的とは思いますがUWSCと動作が異なるのでご報告しておきます。

再現スクリプト

fput(fopen(path, F_WRITE), "hoge")
print fget(fopen(path, F_READ), 2) = empty  //UWSCR:TRUE  UWSC:FALSE
print fget(fopen(path, F_READ), 2) = ""     //UWSCR:FALSE UWSC:TRUE

再現手順

No response

バージョン

1.0.0

不具合発生環境

Windows 10

補足:
empty = ""の問題ですがUWSCは変数にemptyを代入すると扱いが変わるっぽいですね。

a = fget(fopen(path, F_READ), 2) 
b = ""
c = empty
print a = b     //UWSCR:FALSE UWSC:TRUE
print a = ""    //UWSCR:FALSE UWSC:TRUE
print a = c     //UWSCR:TRUE  UWSC:TRUE
print a = empty //UWSCR:TRUE  UWSC:FALSE

UWSC側は整合性がない気がするのでUWSCRで修正して欲しいという訳ではありません。

fgetの実装を確認したところ読み取れなければEMPTYを返すようにしてあったのですが、F_ALLTEXTの場合はおそらく空のファイルを読み出した際に空文字を返しそうな感じになっていました
UWSC方式で空文字を返す方に合わせるか、EMPTYで統一するか悩みどころですね

いや待てよ、空文字を読み出した場合と読み出す行または列が存在しない場合を区別するのにEMPTYのほうが良い気がする (EMPTYであれば読む場所が不正であることがわかる)
そうなると空ファイルを読む場合は空文字を返すほうが正しいか

であればEMPTYを仕様として、ドキュメントにその旨を記載する方向にします
UWSCとは結果が異なるということも明記します

empty = ""の問題ですがUWSCは変数にemptyを代入すると扱いが変わるっぽいですね。

そうなんですよね、UWSCでは同じ式のはずなのに異なる結果を返すという不可解な動きをしているのでこれは明確にUWSCのバグだと考えています
UWSCRだと変数のEMPTYかリテラルのEMPTYか関数の戻り値のEMPTYかを区別する手段が現状ないので、そもそもそのような実装ができません
その区別をするための実装自体は不可能ではないでしょうが、それをやるメリットもないですしね

のでまあ、これに関しては別のissueで議論があったのですけど、さすがにバグであると判断した挙動までは再現しませんよという結論になってはいます

であればEMPTYを仕様として、ドキュメントにその旨を記載する方向にします
UWSCとは結果が異なるということも明記します

承知しました。こちらとしては問題ございません。
よろしくお願いします。