【PHP】下らねぇ質問はここに書き込みやがれ 15

【PHP】下らねぇ質問はここに書き込みやがれ 15 (92ﾚｽ)
上下前次 1-新
通常表示 512ﾊﾞｲﾄ分割ﾚｽ栞

5: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2024/11/06(水) 19:12:32.98 ID:r48zHH+W0

> php_mbregex.c の 473行目のエラー処理が実行されます
> PHP Warning: mb_ereg_replace(): mbregex compile err: undefined callout name in /home/user1/test.php on line 7
onigurumaがphp_mbsgringから見て正しく構成されているかをチェックしてるだけの様に見える
渡す正規表現のエンコードがphp_mbstring側(多分utf-8)と一致してるか等のチェックだと(この時点では)推測する
多分onigurumaのコンパイル時に指定出来るのではないかと(でもonigurumaもutf-8がデフォな気はするが)
という見当でonigurumaソースを見てみる
(なおソースコードは10/24にダウンロードしてた oniguruma-43a8c3f3daf263091f3a74019d4b32ebb6417093)

mbstring.c:472: onig_error_code_to_str(err_str, err_code, &err_info);
　より、
php-8.3.12\ext\mbstring>grep -n -r onig_error_code_to_str *　で出てこないので

oniguruma>grep -n -r onig_error_code_to_str *　で(他多数だが)
src/regerror.c:293:onig_error_code_to_str(UChar* s, int code, ...)

oniguruma>grep -n -r "undefined callout name" * では
src/regerror.c:186:    p = "undefined callout name"; break;

src/regerror.c:186付近を見ると ONIGERR_UNDEFINED_CALLOUT_NAME なので、
>grep -n -r ONIGERR_UNDEFINED_CALLOUT_NAME * すると(他多数だが)
src/regparse.c:1750:    return ONIGERR_UNDEFINED_CALLOUT_NAME;
関数は get_callout_name_id_by_name なので中身を確認すると callout_name_find 結果がNULLの時だと分かる
src/regparse.c:1414: callout_name_find も確認すると、

・GlobalCalloutNameTable がnullか、
・onig_st_lookup_callout_name_table でNULLが返される時にこのエラー

http://mevius.5ch.net/test/read.cgi/tech/1730202739/5

8: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2024/11/06(水) 19:15:55.82 ID:r48zHH+W0

> W, D, S, P などのオプションの追加を検討する必要があります
フラグの追加は php_mbregex.c 内 _php_mb_regex_init_options に追加するだけだから楽勝ではあるが、
問題は php 側をコンパイルする必要がある点だな
なお(良いか悪いかはさておき)、通すだけなら

default:
zend_value_error("Option \"%c\" is not supported", c);
return false;

の部分でエラーにするのを止めて、つまりどんなフラグでも通過させるようにする方が楽
(ただ現状の構成では上記をコメントアウトだけでは駄目で、全部case文で書いて|=ONIG_OPTION*する必要があるが)
というか、俺は952時点ではそうなってると思っていた。つまり、
> 普通はそのエラー自体もライブラリ、つまりonigurumaやpeclに判定させて、throwさせるものだから(952)
と言ったのは、上記ポリシーで全部渡した上で、
onigurumaから「そんなフラグはない」とエラーを返させてそれをphpにそのまま返す、
とした方が、onigurumaのアップデートをタダで受け取れるから
(onigurumaに合わせてphpをアップデートする必要がない＝php側での仕事が減る
『自分でやるしかない事に注力すべき』と言ったとおり、
oniguruma側がやってくれるのなら任せた方が良い、と俺は考えるが、
現状のphpはそうなってないし、何かしら理由はあるのだろう
ちなみにこの構成の場合、フラグをONIG_OPTION_*で構造体に設定して渡すのではなく、フラグ文字列として渡し、
oniguruma内にあるフラグ文字列=>ONIG_OPTION_*変換器に通す(onigurumaが単体で動くのならこのルーチンは内部にある)
この場合、onigurumaのフラグ定義で動作するようになり、
phpの古いフラグと被ってる場合に問題なるが、(＝php側でフラグ名の再定義が出来ない)
見る限りpreg_replace(つまりpcre)と合わせる気もないみたいだし、
oniguruma自身も普通のフラグ名で作られてるようなので、
そのまま通してしまった方が俺はいいとは思うんだがな)
(※とは思ったがonigurumaにはフラグが死ぬほどあるのね…)

http://mevius.5ch.net/test/read.cgi/tech/1730202739/8

12: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2024/11/06(水) 19:24:30.04 ID:r48zHH+W0

なのでこちらは、現状、
・(*SKIP)(*FAIL)の定義自体を見つけられない(が、どこかにあるはず)
　ありがちなのは'SKIP'ではなく、最速の s[i]=='S' && s[i+1]=='K' ... とかの可能性で、
　これも一応探したが、ない…
　高速化の為に探索部分と一体化してて、grep等では探せないのかも…
・(*SKIP)(*FAIL)を探しに行っている関数 onig_st_lookup の定義が見つからない(が、これもどこかに定義されてるはず)
　マクロで書き換えててgrepではヒットしない場合もあるが、一般的にはこれはあまりないはず…
という感じ

上記 fprintf については、
・$pattern = "....(*SKIP)(*FAIL)|[^あ]";を与えた場合、
　'SKIP'と'FAIL'が検索される(と予想)
　そして onig_set_callout_of_name 内
　callout_name_entry 内
　callout_name_find 内
　onig_st_lookup_callout_name_table 内
　onig_st_lookup で検索されるが、検索に失敗する
　(そして onig_st_lookup の定義が見あたらない…)
・何故検索に失敗するのかは、上記fprintfで確定するはずだが、
　もしかするとphpがutf-8でonigurumaがutf-16なのか？
・(*MyFunc)とかやりたいのなら諦めた方がいい
　php側のインタフェースがまるでないので、先は長い
　そこを俺が書いてやるぜ！という勇者ならphp側も歓迎はするだろうが
　(C書けてもonigurumaの仕様を熟知してないと書けない部分だし)

というわけで自身の探索経過と比較してくれれば、辿り方等も分かってくると思う
ちな、ささっと分かるなら、再記すると

・(*SKIP)(*FAIL)の定義部分
・onig_st_lookup の定義部分

を見つけてくれれば確認する

http://mevius.5ch.net/test/read.cgi/tech/1730202739/12

14: デフォルトの名無しさん (ﾜｯﾁｮｲ 617b-8+ss) [sage] 2024/11/06(水) 22:01:44.17 ID:r48zHH+W0

oniguruma/regexec.c:6399: onig_builtin_fail が(*FAIL)の定義
oniguruma/regexec.c:6433: onig_builtin_skip が(*SKIP)の定義
なのは分かった

これらを呼び出してるところは、grep -n -r onig_builtin_fail * では出てこない
そこで、(これはC知ってないと無理だが、)
oniguruma>grep -n -r '#define' * | egrep -v '#define *[A-Z]' で小文字マクロを確認、onig_を付けてるケースが多いので、(※2)
oniguruma>grep -n -r builtin * とすると
src/regint.h:989:/* for definition of builtin callout */
src/regint.h:995:                              onig_builtin_ ## func, 0, 0, 0, 0, 0);\
src/regint.h:1004:                              onig_builtin_ ## func, 0, 0, 0, 0, 0);\
src/regint.h:1013:                              onig_builtin_ ## func, 0, 0, 0, 0, 0);\
src/regint.h:1022:                                onig_builtin_ ## func, 0, (na), (ts), 0, 0); \
src/regint.h:1031:                           onig_builtin_ ## func, 0, (nts), (ts), (nopts), (opts));\
src/regint.h:1040:                              onig_builtin_ ## func, 0, (na), (ts), 0, 0);\
src/regint.h:1049:                           onig_builtin_ ## func, 0, (nts), (ts), (nopts), (opts));\
となり、マクロで呼び出してる

なので、定義自体は存在してて、呼び出し部もある
だから(*SKIP)(*FAIL)の文字列から検索出来てないだけ

http://mevius.5ch.net/test/read.cgi/tech/1730202739/14

29: 前スレ 947 (ﾜｯﾁｮｲ 6274-erF6) [sage] 2024/11/09(土) 01:35:17.88 ID:k7Zpjetb0

NGスレ06 にお返事を書いてましたが連投規制なのか続きを書けなくなりました
agree.5ch.net/test/read.cgi/mango/1715675838/334-n

書けない間についに問題の核心部分を突き止められました！
原因は oniguruma で廃止された onig_init(); を php_mbregex.c で使っていたことでした
github.com/php/php-src/blob/84400eefbb6f09ca7de971f49a86ab26520dfff3/ext/mbstring/php_mbregex.c#L115

PHPを知らない私は PHP_MINIT_FUNCTION(mb_regex) の MINI の部分を見て

「これはバージョン番号が小さい(=古い) oniguruma を使うときのものだな、きっと」

と思ってしまったのが大間違いでした。ググったところ、この関数は
「モジュールがロードされたときに最初に呼び出される関数」だそうです.....(T_T)

ということで新しい初期化関数の onig_initialize() を使った書き方に直したところ、
(*FAIL) や (*SKIP) がPHP上で正常に動作しました

onig_initialize() ※ これは引数が２つ必要なので注意です
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/doc/API.ja#L6

onig_initialize() 周りのコ-ドは oniguruma/sample/callout.c からそのままコピペしました
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/sample/callout.c#L189

こんなことで2週間もスレを占領してしまってすみませんでした..
超優秀な方には感謝感謝です、他の方もありがとうございました！ とても勉強になりました！

良かったら>>23 さんにも教えてあげて下さい、がんばれ23さん！！！

http://mevius.5ch.net/test/read.cgi/tech/1730202739/29

56: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:46:41.16 ID:MhxTwPG60

>>29
解決したのはすごいよ。
普通はたどり着けないからね。ラッキーでど命中したというのはあるが、それにしても、だ。

> 速度面での恩恵が大きい (https://agree.5ch.net/test/read.cgi/mango/1715675838/336)
正規表現にもよるが、'/....ABC/'とか書きたければそうね。
(俺の理解が正しければ)O(n^2)が(*FAIL)でO(1)になるのだから爆速だ。
ただ現在は、こういう「頭が決まらない(＝頭が何でもマッチする)正規表現はバックトラックが激しく発生するので駄目、
後読み/(?<=/等使って頑張れ、となってるが、これらについて、つまり正規表現エンジンの進化の方向としては、

α. バックトラックを正しく理解した上で、制御しきる。（＝ホワイトボックス化)
　この為に(*FAIL)や++等追加する。
β. 単純に速い正規表現エンジンとする。バックトラックの理解はしなくていい。（＝ブラックボックス化)
　ただし内部的な最適化を限界まで行うので、動作の曖昧さが残る。結果、
> 　/^(?>s|ss)$/ does not match "ss".  (https://github.com/kkos/oniguruma/issues/290#issuecomment-1825555154)
　等はバージョンによって動作が異なるので、現実的に使えない。
　つまり、頭から検索する前提でバックトラック制御等を行っている正規表現は動作の保証が出来ない。(＝仕様として追加できない)
　言い換えれば、現在onigurumaで導入してる ?> 等は永久に使えない。

の2つの方向があって、見る限り、onigurumaは明らかにα方向だ。
ただ俺は、βが正解だと思ってるんだな。αはMatzの言う「実装が仕様にはみ出している」から。
つまり、今回も、あるいはバックトラックの理解/制御が必要なのも、「遅い」からであって、
十分速ければこの必要もないし、ユーザーもバックトラックなんて理解したいわけではなく、正規表現を使いたいだけだから、と考える。
富豪プログラミング万歳！！！ってところだ。

http://mevius.5ch.net/test/read.cgi/tech/1730202739/56

63: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:51:33.26 ID:MhxTwPG60

さて読んでて思ったのだが、これ、仕様が矛盾してて、現実的に実装できない可能性も有るのでは？
これは当人も気づいてて言及してるが、実際に矛盾してるかどうかまでは分からないようだ。
> JS also ensures that /\w/iu is the inverse of /\W/iu. (https://github.com/kkos/oniguruma/issues/351#issuecomment-2818389363)
俺も考えてみたが、よく分からん。
単純には、[\w]!==[^\W]でどうにも実装できないケースがあれば、
どのみちいつか breaking change するしか無いので、後腐れなく出来るのだが。

ところで同様の問題は、多分「濁点」にもある。
(この板がunicode許可してるかは知らんので以下見た目意味不明になるかもだが)
Unicodeには、結合文字用濁点(0x3099)があるので、「あ゙」とかも出来る。(表示系が対応してれば前の字と重ねて表示され、あに濁点がつく)
よって、「が(0x304c)」と「が(0x304b,0x3099)」は見た目区別がつかない。
(0x304b,0x3099を表示するのに、通常は、単純にビットマップを重ねるわけではなく、0x304cのフォントが使用されるから)
おそらくこの辺もonigurumaは対策されてるのではないかと思う。
正直、これはヒットしてくれたほうが助かるのは事実。
というかね、ブラウザ(Ctrl+F)ではヒットするが、JSではヒットしないので、
見た目表示されてるのにJSから検索すると存在せず、あれ？ってなったことがあった。

だから見た目、現行の動作は、「仕様的に正しい」。
これは本当に重要で、先日も言ったが、仕様を追加するのはいつでも楽勝だが、削除するのは基本的に無理なので、
おかしな仕様を追加した時点で将来的に詰むのが確約されるから、これは全力で回避しなければならない。
現行の動作は、確かに正しい。
問題は、その場合に異常に遅くなるケースがある、ということであって、
本来は、仕様変更ではなく、速度対策『だけ』で済ませるべき状況であり、実際に高速化すれば何も問題なくなるはず。
とはいえ高速化はもう出来ません、ということなのだろうが、果たしてそうなのか？とは思う。

http://mevius.5ch.net/test/read.cgi/tech/1730202739/63

64: デフォルトの名無しさん (ﾜｯﾁｮｲ 2770-RTB+) [sage] 2025/05/08(木) 21:51:59.95 ID:MhxTwPG60

例えば典型的な糞ッタレ正規表現、
> a.*b.*c.*d.*e   // --- (a)
についてだが、
> a.*+b.*+c.*+d.*+e   // --- (b)
は確かに一つの解だろう。しかしこれは、最速ではない。
人間がやるときを考えれば分かるが、

$len = strlen($str);   // ---(c)
$e = strrpos($str,'e'); // 最後のe
$d = strrpos($str,'d',$e-$len); // eより前の最後のd
$c = strrpos($str,'c',$d-$len); // dより前の最後のc
$b = strrpos($str,'b',$c-$len); // cより前の最後のb
$a = strpos($str,'a',$b-$len); // 最初のa
if ($a<$b) // check

と後ろから検索するのが速く、正規表現にすると

/(?<=(a.*))(?<=b.*?)(?<=c.*?)(?<=d.*?)(?<=e(.*?))$/ --- (d)

となる。が、まあ、(d)だと得られる結果が微妙に異なってしまうので後処理必要だが、(というより同じ結果を得られる正規表現を書けなかったorz)
内部的に自動的にこの方向で高速化してくれ、となる。
単純には、greedyに対してnon-greedyで右から検索すれば多分最速になる。
この辺、バックトラックの指定を事細かく出来る＝走査順が仕様として規定されてしまう＝左から右に走査、となってしまってるのが問題なので、
「任意の最適化の許可」フラグで、右から左に走査することも許可し、(勿論それ以外にもやっていい)
結果的にクソ速いがバックトラック制御は出来ませんよ、が正しい気がする。
(フラグ指定した場合、どう走査されるかはエンジン任せで、
結果的にバックトラック制御を指定してもどう動くか予想できず、実質使えなくなる。
が、問題は速度が遅いことであり、バックトラック制御をするのが目的ではないのでこれでいいはず)

http://mevius.5ch.net/test/read.cgi/tech/1730202739/64

86: デフォルトの名無しさん (ﾜｯﾁｮｲ 33bb-5lkG) [sage] 2025/05/21(水) 21:48:36.13 ID:/jwTY25H0

> 了解です。私は頓珍漢なことを言っていたようです、すみません。 (>>79)
いや謝る必要はまったくない。
ただ、PHP程の歴史があると、仕様変更は結局、
・これまでのコードをメンテしないといけなくなる連中がパニくるため、
・クソ仕様をさっさと更新して欲しい「ご新規さん」は少数派で、多数決的に勝つのは無理
・だからクソ仕様が周知されてて、界隈で「いい加減直そうぜ」とならないと仕様変更されない
　(なのでPHP8で修正された事項も『皆さんご存知のクソ仕様』ばかりのはず。onigurumaはこれに程遠い)

> いえ、これは私がOnigurumaをforkしたリポジトリでのmargeです。
> このmargeは不適切ということでforkしたリポジトリは削除しました、ご指摘ありがとうございました。
> (セキュリティ上の理由でforkしたリポジトリは非表示に出来ないようです)
これもGitHubの仕様が全く意味不明だ。
forkはただのローカルコピーだからしていい、というかむしろやるべきだし、
そもそも好き勝手するためにforkするのだから、何やってもfork元には迷惑はかからないし、issueトラッカーに表示されるのもおかしい。
この辺全く知らないが、もしかすると、宿り木を探してる連中のために、
archive化されたリポジトリについては〇〇が引き継ぐみたいだぞ！と見えるようにしてるのかもしれんが、
仮にそうであっても、forkして自分にとって都合のいいmergeを行って何ら問題ない。
(というか、セキュリティ上の理由って何ぞそれ？ではある。垢無しで全世界公開なのにセキュリティもクソもねえ)

> #ifdef USE_DIFFERENT_CHAR_LENGTH_MATCH_BY_IGNORECASE
#ifdefだからコンパイル時に切り替えだね。
ただコード見る限り、俺が想定してたのとはだいぶ違う。(いいか悪いかは別、というかそこまで読んでない)

> ただ、こういうケースまで実装で対応するのは大変そうですね。
実は動かすだけなら言うほど難しくはない。(現実的な速度が出るかは別問題だが)
ただし分量が死ぬほど多いので、仕様をよく知ってるやつがやらないと話にならない。
(バグ報告〜修正の往復の方が実装の手間を遥かに超えてしまう)

http://mevius.5ch.net/test/read.cgi/tech/1730202739/86

上下前次 1-新書関写板覧索設栞歴

ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.020s