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

2024/10/29(火) 20:52:19.15

!extend::vvvvv:1000:512
!extend::vvvvv:1000:512
★スレ立て時 ↑ が3行以上になるようコピペ

PHPに関する質問スレです

前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 14
https://mevius.5ch.net/test/read.cgi/tech/1663659983/

次スレは>>980以降

VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

2024/10/30(水) 12:35:56.19

PHPで20桁の整数演算をしよう！

2024/11/05(火) 13:23:35.70

GMPでも使ってろ

2024/11/06(水) 19:11:34.41

遅れたが纏めて一応返しておく
(なお前後してる部分もあるので、まず全部読む方がいいかも
※はその時にはそう思ってたが、後になって違うと判明した部分
思考の過程を残した方が参考になると思うので残しておく)

> そのため、ここは一度戦略的に撤退し、次の好機をうかがうことにしました
この判断はあり、というか普通はそうする
理由は俺らプログラマにとっての資産＝時間をかけて作ったもの＝ソースコードであり、
自分のソースコ
ード＝他の誰にも任せられず、『自分でやるしかない事に注力すべき』だから
onigurumaの新機能はいつか誰かが使えるようにしてくれるから、後回しでいい
典型的には既に回答されてるとおり、956,959でラップし、とりあえず自分のソースコ
ードを完成させてしまい、
その後やはり速度等で問題がある場合、
つまり自分で解決しないと先に進まない状況になって初めて今回のように自分で対応し、
その後ソースコ
ードを差し替える
だから最低限は「差し替えが簡単なソースコ
ードにしておく」事で、今回は自然とそうなるので問題はない

今回のような話は試行錯誤的で、
やってても終わりが見えないが、終わるときにはいきなり終わるので、
「もうちょっとで行けそう」的にズルズルと無限に時間を食う事はよくある
なので、一旦本筋に戻る、というのは正しい

ただ、(時間に余裕があるのなら)それでもやり続けるのも正しいが
出来ない≒多くの場合、何らかの技術/知識的に問題があるので出来ない、なので、
全方向的に首を突っ込むだけでも色々蓄積はしていく(とはいえ効率が悪いかもだが)
やれる事を繰り返してても慣れるだけで、本質的な部分では上達しない

2024/11/06(水) 19:12:32.98

> 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が返される時にこのエラー

2024/11/06(水) 19:14:17.28

ちなみに ONIGENC_IS_ASCII_COMPATIBLE_ENCODING の時には ONIG_ENCODING_ASCII にして再度検索してるから、
utf-8ならエラーにはならないはずだが、はて？
まあネタ元は GlobalCalloutNameTable らしいので
oniguruma>grep -n -r GlobalCalloutNameTable *
14件出るが全部このファイル内なので確認すると、どうやら
src/regparse.c:1501: callout_name_entry で作っているらしい
てっきり定数で与えられてる物を違うエンコーディングで検索して失敗してるのかと思いきや、
見る限り毎回全部作り直してるっぽいので、これって正規表現内の名前付きキャプチャ(?<Name>x)のことか？(※勘違い)
ただ、無ければ毎回登録してるだけなので、これが検索失敗するのはそもそもおかしい
(＝だからこそ mbregex compile err: なわけだが)
なお関数は #ifdef USE_ST_LIBRARY によって登録の仕方が変わっており、ここで食い違ってるのかも？(※間違い)
oniguruma>grep -n -r USE_ST_LIBRARY * で(他多数)
src/regint.h:93:#define USE_ST_LIBRARY
なのだがこれは(このファイルがインクルードされる限り)毎回必ず#defineされてる
となると、fprintfでデバッグする気なら、

2024/11/06(水) 19:15:21.89

・regparse.cの1511行目付近で、実際に登録しようとしているnameを出力させる
(例：fprintf(file, "%s %d %s: %.*s", __FILE__, __LINE__, __func__, len, name); と書けるらしい)
・regparse.cの1747行目付近で、実際に検索しているnameを出力させる
(例：fprintf(file, "%s %d %s: 0x%16x: %.*s", __FILE__, __LINE__, __func__, (int)GlobalCalloutNameTable, (int)(name_end-

name), name);)

まあ何を登録/検索しようとしてるか分かれば見当は付くはず(※後に完全に見当付いたが)
おそらく登
録時と検
索時でエンコが違ってて検
索失敗してると推測する