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

2022/09/20(火) 16:46:23.39

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

PHPに関する質問スレです

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

次スレは>>980以降
VIPQ2_EXTDAT: default:vvvvv:1000:512:: EXT was configured

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

2024/10/23(水) 22:18:06.80

なので検索する場合は、Onigurumaが無ければ、
ONIG_SYN_OP2_OPTION_ONIGURUMA　を探し、それもなければ
0x を探す(一応0Xでもいいらしいのでそれも)

とまあ、ここまで書いてると、「そこまで言うならお前が見ろや！」なので見てみる
最新版とか知らんのでpnp.netのdownloadページの8.3.12をDLした(CurrentStable)
ああ俺は、他人のコードを読み足りない、と認識してるから、こういう機会があれば読む事にしているだけだ
今風に言えば、べっ別に、あんたの為に読んだ訳じゃないんだからね！！！(だが男だ)

さて上記検索試すが、空振る。そして後付ではあるが
php-8.3.12>grep -n -r -i OnigSyntaxType *
ext/mbstring/php_mbregex.c:62: OnigSyntaxType *regex_default_syntax;
ext/mbstring/php_mbregex.c:455:static php_mb_regex_t *php_mbregex_compile_pattern(const char *pattern, size_t patlen, OnigOptionType

options, OnigSyntaxType *syntax)
ext/mbstring/php_mbregex.c:489:static size_t _php_mb_regex_get_option_string(char *str, size_t len, OnigOptionType option,

OnigSyntaxType *syntax)
ext/mbstring/php_mbregex.c:595: OnigSyntaxType **syntax)
ext/mbstring/php_mbregex.c:997: OnigSyntaxType *syntax;
ext/mbstring/php_mbregex.c:1268: OnigSyntaxType *syntax;
ext/mbstring/php_mbregex.c:1332: OnigSyntaxType *syntax;
ext/mbstring/php_mbregex.c:1463: OnigSyntaxType *syntax = NULL;
ext/mbstring/php_mbregex.c:1591:static void _php_mb_regex_set_options(OnigOptionType options, OnigSyntaxType *syntax, OnigOptionType

*prev_options, OnigSyntaxType **prev_syntax)
ext/mbstring/php_mbregex.c:1608: OnigSyntaxType *syntax, *prev_syntax;
当たり前だが、変化する値側ではなく、固定的な型名で検索するべきだった

2024/10/23(水) 22:19:18.35

そして順当なら php_mbregex.c:1591:static void _php_mb_regex_set_options なので見てみる
prevをデフォに戻して新しい値をセットするだけのようだ
そもそもprevが何故いるのか？はかなり疑問だが、まあいい
とにかくビットを立ててしまいたいだけなら、ここを改造して、上記βしてしまえば、ここを通る限り常にビット30が立つようになる
コンパイル通るかどうか知らんが、例えば具体的には、

MBREX(regex_default_options) = options;

MBREX(regex_default_syntax) = syntax;
(*syntax)->op2 |= 0x40000000; // これを最後に追加

MBREXはマクロ
#define MBREX(g) (MBSTRG(mb_regex_globals)->g)
MBSTRGもマクロ
mbstring.h:118:#define MBSTRG(v) ZEND_MODULE_GLOBALS_ACCESSOR(mbstring, v)
ZEND_MODULE_GLOBALS_ACCESSORもマクロ
Zend/zend_API.h:255:#define ZEND_MODULE_GLOBALS_ACCESSOR(module_name, v) ZEND_TSRMG(module_name##_globals_id,

zend_##module_name##_globals *, v)
Zend/zend_API.h:270:#define ZEND_MODULE_GLOBALS_ACCESSOR(module_name, v) (module_name##_globals.v)
2つ出るのは#ifdefと相場が決まっており、今回も#ifdef ZTS らしいが、ZTSってなんだっけ？
まあとにかくこの辺はここまででいい、とにかく更新してるだけっぽいし

2024/10/23(水) 22:21:26.39

その他、
ext/mbstring/php_mbregex.c:489:static size_t _php_mb_regex_get_option_string
ext/mbstring/php_mbregex.c:594:static bool _php_mb_regex_init_options
とか、いかにもなので君には分かるだろう
真面目に直すのならこの辺だね

ちなみに regex_default_syntax を修正してもいけるはず。これは
ext/mbstring/php_mbregex.c:84:pglobals->regex_default_syntax = ONIG_SYNTAX_RUBY;
とモロクソに書いてある
君の読み通りなら、そこを

pglobals->regex_default_syntax = ONIG_SYNTAX_ONIGURUMA; // RUBYからONIGURUMAに変更
ついでに
ext/mbstring/php_mbregex.c:601:*syntax = ONIG_SYNTAX_ONIGURMUA; // RUBYからONIGURUMAに変更

なのだろうね
grep -n -r ONIG_SYNTAX *
でONIG_SYNTAX_RUBYが引っかからないから、おそらくONIG_SYNTAX_RUBYはoniguruma側で定義されてる
だからoniguruma側で同様にgrepして ONIG_SYNTAX_ONIGURUMA が定義されてればいけるかも
てかこれ見る限り、毎回initしてるのか？(まあdllならそうかもだが)
そして _php_mb_regex_init_options内case '*' の部分をphp.iniかどこかで設定出来るようにしてるはずではあるが

ただ普通に考えて、prev_syntaxって何ぞ？ではある
regexで「今回の」文法を切り替えるのは分かるが、「前回の」は明らかに要らないので、
それがある＝何か無理矢理切り替えて動かしてる感あり、なので、単純にビット立てるだけでは駄目かもよ
ダラダラ書いたけどこんな感じ

とはいえ、君はほぼ辿り着いてるよね
php_mbstringのコンパイル環境の立ち上げがすんなり行くかはやってみないと分からないが

2024/10/23(水) 22:21:59.96

あとついでに言うと、推定だが、順当には、

当初：php->onigurumaを直接呼び出し

おそらくonigurumagaの更新でAPIが変わって、

現在：php->php_mbstring->oniguruma と呼び出し、
php->php_mbstring間のAPIは固定、
php_mbstring->onigurumaでonigurumaのAPI変更に対応、
つまりonigurumaが変更されてもphp_mbstringの変更のみで対応し、php 本体は一行も変更無しでいけるように分離した、
だと思うので、君の予想する「oniguruma用に何かしてるコード」はphp_mbstring側に全部突っ込まれてるはず
まあこれも一般論だが

2024/10/23(水) 22:31:46.47

>>967
分かる範囲だが一応訂正

× (最近使ってないなら文法間違ってるかもだが)
○ (最近使ってない　か　ら文法間違ってるかもだが)

2024/10/23(水) 22:52:29.22

さらについで
ONIG_SYNTAXは仕様としては任意のビットを立てたり落としたり出来るはずだが、
実際はこの手の奴は大体テストが甘くて、組み合わせによっては動作しなかったりする
ではどうするか？と言えば、テスト済みであろう組み合わせに出来るだけ近い物を使う
今回ならRUBYかONIGURUMAに一番近いものだが、まあ、両方とも似たり寄ったりだな

しかしよく見ると、RUBY 指定なら ONIG_SYN_OP2_ASTERISK_CALLOUT_NAME は立ってるではないか
php_mbstringのソースだけ見るとデフォはRUBY指定だから動くはず
となると何らかの理由で _php_mb_regex_init_options で他指定に切り替えられてるのか？
ならば手抜きで直すなら、
ext/mbstring/php_mbregex.c:607-656を全部コメントアウトして case 文を無視、
何をどう指定されても ONIG_SYNTAX_RUBY(あるいはONIG_SYNTAX_ONIGURUMA) になるようにしてしまうとか、かな

2024/10/23(水) 23:37:30.51

>>964
てゆうかすいません、モロクソに書いてましたわ
dllだけ差し替えて'r'指定で行けるはずですわ
もうちょっと眺めて投稿すべきだった(これもかもだが)

（すまぬが引っかかるのでバラバラに落とす)

2024/10/23(水) 23:40:00.93

_php_mb_regex_init_options は各関数で毎回呼ばれてる
(_php_mb_regex_ereg_replace_execからも)

2024/10/23(水) 23:41:25.78

そしてこれをPHPから呼ぶのが mb_regex_set_options で、

2024/10/23(水) 23:42:52.32

> Regex 構文モード(ひとつだけ設定可能です)

2024/10/23(水) 23:43:08.35

> https://www.php.net/manual/ja/function.mb-regex-set-options.php
とモロクソ書いてますな
そして何故かそのphp.netページにはデフォが何か書いてないが、
'r'指定すればRUBY指定(=ONIG_SYN_OP2_ASTERISK_CALLOUT_NAMEがON)になる
'p'指定でもいけるかも？

そしてこのフラグは mb_ereg_replace でも使えるらしい。つまり、
mb_ereg_replace(
string $pattern,
string $replacement,
string $string,
?string $options = null <- ここに指定、例えば 'r' or 'p'
): string|false|null

これで使えるなら、dllだけ差し替えればC側の修正は不要(そして多分これで上手く行く)

2024/10/23(水) 23:43:51.89

それでも駄目、或いはRUBY指定やPERL指定では使えない機能も使いたいなら、
_php_mb_regex_init_optionsに

case 'o':
*syntax = ONIG_SYNTAX_ONIGURUMA
break;

を追加して、'o'指定してやるとかすればいけるはず
敗因は、oniguruma側で細かくregexを切り替えられる事を知らない人にとっては
> Regex 構文モード(ひとつだけ設定可能です)
とか意味不明だからだな
最初にそこを言ってくれてれば、ピンと来た人がいたかも？

2024/10/24(木) 01:07:24.54

>>978
訂正、perlなので' p と思ってしまってたが z だった orz

× 'p'指定でもいけるかも？
○ 'z'指定でもいけるかも？

× 例えば 'r' or 'p'
○ 例えば 'r' or 'z'

あと var_dump(mb_regex_set_options(null)); でデフォを確認出来る
多分 "r" と出るはず

あと
>>973
> しかしよく見ると、RUBY 指定なら ONIG_SYN_OP2_ASTERISK_CALLOUT_NAME は立ってるではないか
> php_mbstringのソースだけ見るとデフォはRUBY指定だから動くはず
の部分も一部訂正だが、これは俺だけが悪いのではなく、GitHubのSYNTAXページも間違ってるな
上側の説明部分では

> 28. ONIG_SYN_OP2_QMARK_BRACE_CALLOUT_CONTENTS (enable (?{...}))
> Set in: Oniguruma, Perl, Perl_NG
> 29. ONIG_SYN_OP2_ASTERISK_CALLOUT_NAME (enable (*name))
> Set in: Oniguruma, Perl, Perl_NG
となってて、Onigurumaならフル機能のように書かれてるが、下の表だと 28,29はOnigurumaでは付いてない
まあどっちが正しいのかは謎だが、意味不明な挙動するのはこの辺の問題もあるかもよ
これでは結局の所、RUBYやONIGURMUA指定で欲しい機能(29と30か？)が動くかどうかがよく分からんし
(まあ自前で立ててやればいいんですけどね)

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/24(木) 12:35:15.79

ありがとうございます、おかげ様でゴールが見えてきた感じです
すごい解析力に脱帽でした、読みながら「すごいな～」を連発してしまいました
ちょっと昔に DAN KOGAI さんを見たときも衝撃を受けましたがそんな感じでした

本当は (*FAIL) が動くのを確認してからレスしたかったのですが
何かにハマっているらしくまだ成功していません
しかしもう PHP の問題というより oniguruma の問題ですので
ここから先は自力でなんとかなりそうです

> 28. 29.
これは表が間違ってます、以下は ONIG_SYNTAX_RUBY のオプション指定です
https://github.com/kkos/oniguruma/blob/43a8c3f3daf263091f3a74019d4b32ebb6417093/src/regparse.c#L122-L162

#define ONIG_SYNTAX_RUBY (&OnigSyntaxRuby)
https://github.com/kkos/oniguruma/blob/43a8c3f3daf263091f3a74019d4b32ebb6417093/src/oniguruma.h#L444

今は (*FAIL) が使えるようになるかの手っ取り早い確認のために oniguruma ライブラリ側をいじり、
上記の ruby のオプション指定に oniguruma のものをコピペして動くかどうかを試していますが
今のところ結果が変わりません (ライブラリの置き換えに失敗している？)

ちょっと日数がかかるかも知れませんが成功したらご報告に伺います、ありがとうございました！

2024/10/24(木) 22:06:48.35

>>981
> これは表が間違ってます
確認した。md打つときに列が一個ずれて、onigがyesになるべき所がRubyの列に入ってるんだな
誰か余裕があったら指摘してあげて

> 上記の ruby のオプション指定に oniguruma のものをコピペして動くかどうかを試していますが
いいね。この方が早そうだ

> ちょっと日数がかかるかも知れませんが成功したらご報告に伺います、ありがとうございました！
はいまあ頑張って

ちなみに１つバグ、というか不一致を発見した
php_mbregex.c内、_php_mb_regex_init_options関数で、単純にRubyの r 指定等すると上書きしている為、
『最初に』指定しないと正しく動作しない(それ以前に指定したフラグが全部キャンセルされる)
しかしphp.netには『最後に』と明記してある
> モードを設定する際には、モード文字は最後に指定しなければなりません。
> https://www.php.net/manual/ja/function.mb-regex-set-options.php
これも誰か余裕有ったら指摘してあげて。勿論報告者の手柄にしていい

本来はPCRE側、つまりpreg_replaceと同様にすべき
となると多分フラグの順は問わないので、
2パスにして1周目でRegex構文モードを、2周目で各フラグを設定するようにCを修正するのが正しい
ドキュメント修正で済ませる場合は上記の通り、『最後に』と修正すれば終了
(Cの修正案が要るなら俺が書いてもいい、が、手続きとか知らんし面倒だから誰かやってくれ、勿論報告者が発見した事にしていい)

だからまあ、挙動不審なのはもしかするとフラグの指定順がまずいのかも

2024/10/24(木) 22:08:58.49

> すごい解析力に脱帽でした
お世辞乙だがマジレスすると、実は普通に読めて、それがOSSの定義だったりするので、そんなにすごくもない
phpも30年間OSSとしてずっとメンテされており、当たり前だが多くの人が読めるからメンテ出来てる
だから逆に言えば、読めないコードはOSSとしては生き残れないし、30年は淘汰に十分な期間ではある
よって、長寿OSS、つまりphpやGNUやLinuxは、OSSに参戦するレベルの連中ならある程度読めて当然で、
「僕が読めないから汚いコ
ードだ」と寝言ほざいてる奴には「お前の頭がOSSの域に達してないだけだ馬鹿タレ」と返していい

ただ読めると言っても実際に読んでいるわけではなくて、
この仕様ならこういう作りだろうなという予測通りになっているのをなぞっているだけ
だから逆に、初心者や、まだ淘汰されてないOSSのコ
ードとかは、普通に読めない
(読む価値無いから無視でいいのだが)

だから今回は
> 以下のページは oniguruma の各パーツごとのオプション名を説明するページです
これが大きかった
そしてこれがpnp.net上のRegex構文モードと対になってるのが分かると、なるほどね、となった
まあ結局、一通り出来るようになって、書くのには苦労しなくなると、あとは仕様の理解度で差が出る、ということ

php_mbregexのコ
ードは悪いコ
ードではないね
愚直にやってるだけのドベタなコ
ードで、すごくもないが、でもこういうコ
ードがOSSとしては長生きするのだろうよ

（変な改行はNGワード逃れ)

**947** (ﾜｯﾁｮｲ d274-nV0L) · 2024/10/25(金) 21:53:01.03

> OSSに参戦するレベルの連中ならある程度読めて当然

これが出来るようになることがどれだけすごいことか..
ここでこうやって語って下さるだけでも私含め誰かのためになるめちゃめちゃ
貴重な存在ですよ、いつまでも元気で現役して下さい！

> OSS 淘汰
後で手を入れる人のことまで考えてコーディングされていたんですね
そこまで考えてませんでした、目からうろこです

> 間違いの報告
私はC言語を知らないので間違いの確認作業が出来るか自信がありませんが確認出来たら
報告しに行きますね (ここの回答者様のほうが適任だと思いますのでどなたか余力のある方は是非..)

2024/10/26(土) 20:57:24.64

>>984
> 私はC言語を知らないので
それでソースファイル当たるとは勇者だな。ただ姿勢としては正しい
ソースなんて読める読めないではなく、読む読まないだし、
そもそも読めない奴こそ勉強になるから読めであり、
読める奴(＝そのコード構成が自分でも組める奴)が読んでも得る物はあまりない

> 間違いの確認作業が出来るか自信がありませんが確認出来たら
> 報告しに行きますね
Cに関しては俺がフォロー出来るが、それ以前にバグって無さそう(すまんが俺の勘違いっぽい)
よく見ればフラグは optm |= で溜めてて、文法の切り換えは *syntax = なので上書きしてない
だから正確には、

× モード文字は最後に指定しなければなりません。（現在の表記)
○ 最後に指定したモード文字が有効になります。

ではあるが、現在の表記でも問題はないはず

なおonigurumaの表の間違いはGitHubのissuesに凸すれば多分本人(kkos)がすぐ直してくれる
そちらはonigurumaをよく知ってるみたいなので、こちらはやってみてどうぞ

**947** (ﾜｯﾁｮｲ 3374-ohr8) · 2024/10/27(日) 14:13:33.60

> そもそも読めない奴こそ勉強になるから読めであり
そうですね、読んでて色々勉強になってます
書けと言われたらさっぱりですが読むほうでは少しだけ進歩したな、とは感じます

> それ以前にバグって無さそう
これは良かったです、正直私には荷が重かったのでw

> モード文字は最後に指定しなければなりません
これは mbstring の作者さんが意図するところがはっきり分からないので悩みます
「最後の文字だけ取り出せば指定されているモードが分かる」という仕様に
することを視野に入れているのかも知れませんし..

一応英語のページも見ましたが日本語と同じ意味で書いているようです
https://www.php.net/manual/en/function.mb-regex-set-options.php

> oniguruma の表
この SYNTAX.md は oniguruma 作者さんが作ったページではなく第三者が作ったものを
マージしたものらしく、ページが作られてから1年弱で更新が止まってます
https://github.com/kkos/oniguruma/commits/master/doc/SYNTAX.md

最後の更新から5年近く経っていて情報も古くなっています
私がやるならこのページを oniguruma 6.9.9 のものに更新します
しかし今は php で (*SKIP) を動かすことを目指しているのでその後にやりますね

oniguruma で指定されている option を読み込んであの表を出力するプログラムが
あったら便利そうです、いつか作るかも知れません

2024/10/28(月) 10:05:20.25

>>986
言い方が悪かったかもしれないが、php.netの表記は直す必要がない。(直すべきではない)
プログラミング等においては、

ドキュメント記載の動作範囲⊆実際の動作範囲

である事は絶対に必要だが、書いてない範囲は動いても動かなくても問題ないから。
(今回は、最後に書けば確実に動くので問題ない。
記載を変更したら何か変更があったかと勘ぐられ、余計におかしくなる)
だからphp側については今回は何もする必要がない。

> これは mbstring の作者さんが意図するところがはっきり分からないので悩みます
これはちと違ってて、仕様は実装に依存すべきではないし、してはいけない。
というか、仕様を変更するとこれまで動いてたコートが動かなくなる(＝互換性が無くなる)可能性が出てくるので、
原則として、仕様は追加は出来るが削除は出来ない。
逆に実装は変わるものだし、(互換性を保たれている限り)変わってもいいものだ。
だから仕様が実装に依存した場合、初期実装は楽だが、わりと早々に破綻する。
よって、本来は、最初の最初に仕様を未来永劫変更せずに済むレベルまで練るべきだし、
多少実装が困難な仕様でも、それが良い仕様なら、頑張って実装するしかない。
(主従関係でいえば、仕様が主で実装が従)

2024/10/28(月) 10:05:40.31

ただ、

○　ドキュメントを読めば使える
◎　ドキュメントを読まなくても使える

なので、今回はグダグダ言わずにpcreと全て揃えるのが理想で、目指す所は
既存のコードを mb_* とするとマルチバイト対応になるだけで、全て動く、ではあるが、
現実的には無理だし、phpの場合は仕様自体がわりとグダグダなので、
多少でも綺麗にしていく為には新規部分は(従来の汚い仕様を無視して)綺麗に作るしかなく、
まあ許容範囲だと思うよ。

見た目、

A, 元々は記載通り「最後に書く必要があった」が、pcreと揃えるよう修正して「いつ書いても動く」ようになった
B. 元々何も記載無かったが、複数書いた場合等の動作が曖昧になるので、
　「確実に動く条件」を記載するように求められ、書いた

ように見える。
なお仕様を自由に決めて良いなら、
そもそも「モード」を「フラグ」に突っ込むべきなのか？という話で、
(php.netでは纏めて「オプション」「パターン修飾子」と呼称されてるので曖昧になってる)
例えばJSなら

String.replace(/regular expression/flags, replacement, mode); // modeでRubyやonigurumaモードを切り替える

で終わってた気がするし、
これなら「ひとつしか指定出来ません」「最後に指定しなければなりません」はそもそも必要なくなる。
しかし使いもしない引数を無駄に増やすのもよろしくないし、フラグに突っ込んでしまえ、の判断もありだろう。
(pcreもそうなってるし)

2024/10/28(月) 10:05:57.25

> しかし今は php で (*SKIP) を動かすことを目指しているのでその後にやりますね
それで正しい。義務感でやるものではないし、面倒なら放置でいい。
(というかこの位緩くないと続かない。だいたい昨今のSNS疲れとかは義務感から来てるものだし)

だからまあ、「この表は自分も今後とも使うので正確であって欲しい。
とりあえず自分用に更新版作ったから上げとく」位でいい。
そしてそれをpythonにやらせたのなら、それもついでに上げとく、程度で十分だ。

2024/10/29(火) 00:01:17.52

堂島の龍・・・って言ったんだ

**947** (ﾜｯﾁｮｲ 3374-ohr8) · 2024/10/29(火) 11:56:37.23

> php側については今回は何もする必要がない
了解です、これは分かってましたので大丈夫です

> 原則として、仕様は追加は出来るが削除は出来ない
言われてみれば確かに.. 実装を仕様にしたせいで実際に破綻した経験もあったり(ぉぃ)

> pcreと全て揃えるのが理想
確かにそうですね

> A. B.
なるほど、"仕様が主" ということを考えると納得の推察です

> フラグに突っ込んでしまえ
それでオプションとモードが混ぜてあったんですねｗ

> 義務感でやるものではない
そうですね、でも SYNTAX.md の更新は私がやりたいと思ってるのでやると思います
ミスが出ないように少しづつ進めるつもりです、なので完成は来年になるかも知れません
ただ、私にはオプションの説明文は書けないのでソースのコメントをコピペするだけの
手抜きになると思います ( "説明文 == 仕様" なので )

PHP で (*SKIP) を使えるようにする件もあと少しでなんとかなりそうです
使えるように出来たら修正箇所を書きにまた来ます、ありがとうございました！

2024/10/29(火) 14:57:45.06

すまんけど参考に問題と結論をまとめてほしい

2024/10/29(火) 20:54:54.00

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

2024/10/29(火) 22:11:10.45

>>992
問題： PHPで (*SKIP) が使えない (>>947)
結論：現在は使えないのが仕様

php8.3.12(最新安定版)ではphp_mbstringが対応していない
oniguruma6.6.9(最新リリースバージョン)にも入ってない(開発したばかりで未リリース状態)
なので通常は>>956,959で公式リリースを待つが、
パフォーマンスの問題、或いは(現在開発中のphpアプリの)リリース時には使えるようになっているという読み等で、
GitHub上のonigurumaソースを自前でコンパイルして接続して使うのは自由
この場合の詳細は247が成功した後に報告してくれるから待てばいい

現在の作戦(981)の内容は以下(マクロは大文字で表記)
onigurumaは設定を自由に変更出来る
いくつかあるプリセットの内、ONIGURUMAを指定すれば(*SKIP)が使えるが、RUBYを指定しても使えない
現在のphpではデフォでRUBY指定であり、ONIGURUMA指定は出来ない --- (α)
なので、oniguruma側のRUBY設定値をONIGURUMA設定値で上書きし、
php側でRUBY指定しててもONIGURUMA指定での機能が使えるようにする
これだとonigurumaの再コンパイルだけで済むはず(=php_mbstringは変更無く使える)

この場合の問題は、ruby指定とoniguruma指定で完全な互換性がなかった場合に、(なお実際どうなのかは知らん)
他ソフト(laravel)等と組み合せると一部誤動作する可能性が出てくる事だが、
この場合はRUBYではなくEMACS等、
どう考えても誰も使ってないであろうマクロを潰せばいいだけなので、大した問題ではない
(とはいえ商用用途ではこれも許されないだろうが)

2024/10/29(火) 22:42:58.65

真面目に直すなら、αを修正してphp側からONIGURUMA指定出来るようにすればいい
これは970に書いたとおり、
php_mbregex.c:489:static size_t _php_mb_regex_get_option_string
php_mbregex.c:594:static bool _php_mb_regex_init_options
の2関数を修正すればよく、下側は979に書いたとおり以下3行追加、上側はその逆を追加するだけ(多分)

case 'o':
*syntax = ONIG_SYNTAX_ONIGURUMA
break;

この辺やる気有るのならCのソースは俺が書いてもいいが、報告その他は全部やってくれ
報告の仕方は https://www.php.net/get-involved の通り
ただしバグ修正ではなく仕様追加なので、メンテナの判断により(ソースコードが妥当でも)却下される可
能性はある(改行は規制回避)

>>994 すまぬ一部修正、規制に引っかかったついでに最後の段落書き足したら大文字にするのを忘れた
× ruby指定とoniguruma指定で
○ RUBY指定とONIGURUMA指定で

**947** (ﾜｯﾁｮｲ 3374-D2cl) · 2024/11/02(土) 11:20:08.91

どうやら正規表現の syntax を RUBY から ONIGURUMA に変えるだけではダメそうです
この変更で (?W) が使えるようになったので syntax の切り替えは出来ているのですが、
正規表現に (*FAIL) や (*SKIP) を使うとエラーになります

php_mbregex.c の 473行目のエラー処理が実行されます
github.com/php/php-src/blob/2b10cd1bebde7b9844ebb6e3e60127dfe7b195c5/ext/mbstring/php_mbregex.c#L473

これを解決するには php_mbregex.c と onigurumaライブラリを深く理解する必要があり、
このスレのみなさんにとっても簡単な問題ではないと思います

そのため、ここは一度戦略的に撤退し、次の好機をうかがうことにしました
長々とお付き合い下さりありがとうございました！

**947** (ﾜｯﾁｮｲ 3374-D2cl) · 2024/11/02(土) 12:21:06.68

詳細は以下のスレに書いておきました
agree.5ch.net/test/read.cgi/mango/1715675838/323-325n

C言語をいじるならデバックの仕方を知らないと話にならないようなので
そういうことを覚えるのにかなりの時間がかかりそうです、なのでこの件は一旦保留にさせて下さい
( fprintf を仕込んで ./configure, make, make install ではラチがあかなくなったので)

**947** (ﾜｯﾁｮｲ 6274-erF6) · 2024/11/03(日) 21:59:48.17

補足: onig_init() は oniguruma の古いバージョンが使われたときに備えてのものでした
なので問題ありませんでした

現時点では正規表現に (*FAIL) や (*SKIP) を使うとエラーになる問題は
「PHPのインストール時に (*FAIL) が実装される前の oniguruma が入れられていて
それが使われているのではないか」という仮説を立てています

(*FAIL) が実装される前の oniguruma が使われていたなら「 "FAIL" なんて名前知らない！」と
言われてもおかしくないので..

**947** (ﾜｯﾁｮｲ 6274-erF6) · 2024/11/04(月) 01:55:48.60

↑の仮説は否定されました

oniguruma は最新Master branch版で間違いありませんでした　
oniguruma 6.9.9 で Fix されたバグが直っているのを確認しました

また、古いバージョンの oniguruma が入っていないことを確認しました　
libonig-dev なども含めて他の oniguruma は１つも入っていませんでした

**947** (ﾜｯﾁｮｲ 6274-erF6) · 2024/11/05(火) 00:51:48.35

oniguruma 付属のテストファイル /sample/callout.c では (*FAIL) や (*SKIP) が動くので、このテストファイルのコ-ドを php_mbregex.c に移植して動かしてみました (コンパイルエラーを回避するための最低限の変更のみしました) そしてPHPを動かしてみたところ、問題のエラーと同じエラーが出ました

oniguruma 側でのエラーコード: -229
github.com/kkos/oniguruma/blob/f6723fd940b993b39b1535f71c8695867a5e92d1/src/oniguruma.h#L640

これにより、問題の原因がPHP側にあることが確定しました
しかし php_mbregex.c を読んでもこの問題を起こしそうな箇所は見当たりません

原因はコ-ドではなくPHPの環境にあるのかも知れま１０００

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 776日 8時間 5分 26秒