【PHP】下らねぇ質問はここに書き込みやがれ 15 (43ﾚｽ)
上下前次1-新
1: (ﾜｯﾁｮｲ 5b7b-vCJ4) 10/29(火)20:52 ID:zqRlJI/00(1) AAS
!extend::vvvvv:1000:512
!extend::vvvvv:1000:512
★スレ立て時 ↑ が3行以上になるようコピペ
PHPに関する質問スレです
前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 14
2chｽﾚ:tech
次スレは>>980以降 VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured
2: (ﾜｯﾁｮｲ fbe7-kvRr) 10/30(水)12:35 ID:6wM0eSwC0(1) AAS
PHPで20桁の整数演算をしよう！
3: (ﾜｯﾁｮｲ 1225-p9Y/) 11/05(火)13:23 ID:nu4YBPFR0(1) AAS
GMPでも使ってろ
4: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:11 ID:r48zHH+W0(1/16) AAS
遅れたが纏めて一応返しておく
(なお前後してる部分もあるので、まず全部読む方がいいかも
※はその時にはそう思ってたが、後になって違うと判明した部分
思考の過程を残した方が参考になると思うので残しておく)
> そのため、ここは一度戦略的に撤退し、次の好機をうかがうことにしました
この判断はあり、というか普通はそうする
理由は俺らプログラマにとっての資産＝時間をかけて作ったもの＝ソースコードであり、
自分のソースコ
ード＝他の誰にも任せられず、『自分でやるしかない事に注力すべき』だから
onigurumaの新機能はいつか誰かが使えるようにしてくれるから、後回しでいい
省16
5: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:12 ID:r48zHH+W0(2/16) AAS
> 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 * で出てこないので
省11
6: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:14 ID:r48zHH+W0(3/16) AAS
ちなみに 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: なわけだが)
省5
7: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:15 ID:r48zHH+W0(4/16) AAS
・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);)
まあ何を登録/検索しようとしてるか分かれば見当は付くはず(※後に完全に見当付いたが)
おそらく登
録時と検
索時でエンコが違ってて検
索失敗してると推測する
8: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:15 ID:r48zHH+W0(5/16) AAS
> 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時点ではそうなってると思っていた。つまり、
省16
9: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:16 ID:r48zHH+W0(6/16) AAS
> oniguruma 付属のテスト用ファイル /sample/callout.c では (*FAIL) と (*SKIP) が問題なく動きます
> RUBY オプションを ONIGURUMA オプションで上書きし、実行時の syntax に RUBY を指定した状態で
> (*FAIL) と (*SKIP) が正常に機能します
つまりonigurumaは正常にコンパイル出来ている
> onig_init();
については947自身で答えが出てるのでよしとして、
> それが使われているのではないか」という仮説を立てています
結局の所、新しくコンパイルしたdllが使われてるか断定出来ないからだと思うが、
上記の通り、エラー吐いてる箇所(＝そこを通ってると確実に言える場所)にfprintf仕込んでしまえば、
fprintf出力されれば、新しくコンパイルした物、そうでなければ古いまま、と断定出来る
省13
10: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:19 ID:r48zHH+W0(7/16) AAS
ちなもうちょっといけるかと思って callout_name_entry を呼び出し元の onig_set_callout_of_name を
oniguruma>grep -n -r onig_set_callout_of_name * すると(他多数)
doc/CALLOUTS.API.ja:98:# int onig_set_callout_of_name(OnigEncoding enc, OnigCalloutType type, ,,,
doc/SYNTAX.md:786:function set in `onig_set_callout_of_name()` will be invoked, passing the given name
が引っかかるのだが何ぞこれ？
11(1): (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:23 ID:r48zHH+W0(8/16) AAS
SQLiteと同様に、onigurumaはユーザーC関数を登
録して正規表現内から呼び出せたりするのか？
phpにはこのインタフェースはなさそうだが
というかこの辺はそちらの方が詳しいはず
と思って SYNTAX.md の方見たら
> 29. ONIG_SYN_OP2_ASTERISK_CALLOUT_NAME (enable (*name))
なのでまんま君が使いたい機能か
となると(*FAIL)(*SKIP)は CALLOUTS.BUITIN に定義されてるはずなので、この定義の検索を失敗している事になる
この辺を調べようとするが、
mbstring>grep -n -r "FAIL\\W" *
省9
12: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)19:24 ID:r48zHH+W0(9/16) AAS
なのでこちらは、現状、
・(*SKIP)(*FAIL)の定義自体を見つけられない(が、どこかにあるはず)
ありがちなのは'SKIP'ではなく、最速の s[i]=='S' && s[i+1]=='K' ... とかの可能性で、
これも一応探したが、ない…
高速化の為に探索部分と一体化してて、grep等では探せないのかも…
・(*SKIP)(*FAIL)を探しに行っている関数 onig_st_lookup の定義が見つからない(が、これもどこかに定義されてるはず)
マクロで書き換えててgrepではヒットしない場合もあるが、一般的にはこれはあまりないはず…
という感じ
上記 fprintf については、
・$pattern = "....(*SKIP)(*FAIL)|[^あ]";を与えた場合、
省18
13: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)20:57 ID:r48zHH+W0(10/16) AAS
ごめん間違ってた(>>11)
× > mbstring>grep -n -r FAIL *
○ > oniguruma>grep -n -r FAIL * のつもりが、やってなかった
やればぞろぞろ出てきたので、また続き報告します
14: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)22:01 ID:r48zHH+W0(11/16) AAS
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);\
省8
15(2): 947 (ﾜｯﾁｮｲ 6274-erF6) 11/06(水)22:04 ID:D3puRbUV0(1/2) AAS
ありがとうございます、規制に引っかかったのでとりあえずこちらに書きました
agree.5ch.net/test/read.cgi/mango/1715675838/333
向こうにも書きましたがもう調べて頂かなくて大丈夫です、すみません..
16: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)22:04 ID:r48zHH+W0(12/16) AAS
同様に onig_st_lookup を探す
oniguruma>grep -n -r st_lookup * で
src/regint.h:241:#define st_lookup onig_st_lookup
src/st.c:237:st_lookup(st_table* table, register st_data_t key, st_data_t* value)
と分かる
中身見たら FIND_ENTRY を呼んでおり、これはすぐ上 src/regint.h:224:#define FIND_ENTRY で定義されてる
ちなみにすぐ下 src/regint.h:271:st_insert(register st_table* table, register st_data_t key, st_data_t value)
で毎回エンコードに合わせて作ってる雰囲気
なのでやはり、phpとonigurumaの正規表現のエンコ
ードが異なってて検索失敗かと
省4
17: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)22:06 ID:r48zHH+W0(13/16) AAS
多分onigurumaをコンパイルする際に『phpとやりとりする』（＝APIの)正規表現の文字エンコ
ードを決められる
多分コンパイルオプションにあるから確認してみて
なおこれは対象文字列のエンコ
ードとは違うので注意
phpで言うと、
mb_ereg_replace(
string $pattern, <- 今問題になってるエンコ
ードはこれと
string $replacement, <- これ
省14
18: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)22:23 ID:r48zHH+W0(14/16) AAS
>>15
読んだ
> あなたのような優秀な方を空回りさせてしまうのは申し訳無さすぎますので..
これは気にする必要ない
俺は「たまには他人のコードも読むべき」と認識してるから、機会見つけて読んでるだけ
一人で読んでても仕様とか知らんしハマるので、他人がいるときに合わせて読んでるだけだから
実際君はかなり仕様を知ってるし、結果的に辿りやすくなってる
19: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)22:25 ID:r48zHH+W0(15/16) AAS
> oniguruma には自分で任意の (*hoge) を作って oniguruma に登録することが
> 出来るという機能があります
あーやっぱこれ目当てですか
> そこで php_mbregex.c の中で任意の (*hoge) を作って oniguruma に登録し、
> test.php を実行して任意の (*hoge) が正規表現のパーツとして認識されるか
> どうかを確認したところ、ちゃんと認識されました
さらっと書いてるけどこれは結構ハードル高いはず、まあ動いたのならすごいが
20: (ﾜｯﾁｮｲ 617b-8+ss) 11/06(水)22:25 ID:r48zHH+W0(16/16) AAS
> なので、(*hoge) の名前が文字化けして見つからないという訳ではなさそうです
orz、ハズレか…
> PHPでこの機能が使えているということは FAIL や SKIP も自前で
> 登録し直して使うことが出来るようになるかも知れません
まあ既に動いているのなら行けるはずではあるが、本来は書くのはエグいはず
コピペで移植してしまえであれば、
src/regint.h:989 の辺りから定義をコピペして php_mbreegxをコンパイルしてしまえば
php_mbregexがonigurumaとのキメラになるが動けば使えるはず
まあ頑張ってちょ
上下前次1-新書関写板覧索設栞歴
あと 23 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.014s