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とは結果が異なるということも明記します
承知しました。こちらとしては問題ございません。
よろしくお願いします。