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

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

PHPに関する質問スレです

前スレ
【PHP】下らねぇ質問はここに書き込みやがれ 14
http://2chb.net/r/tech/1663659983/

次スレは>>980以降

---

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

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

GMPでも使ってろ

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

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

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

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

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

ちなみに 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でデバッグする気なら、

・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);)

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

> 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にはフラグが死ぬほどあるのね…)

> oniguruma 付属のテスト用ファイル /sample/callout.c では (*FAIL) と (*SKIP) が問題なく動きます
> RUBY オプションを ONIGURUMA オプションで上書きし、実行時の syntax に RUBY を指定した状態で
> (*FAIL) と (*SKIP) が正常に機能します
つまりonigurumaは正常にコンパイル出来ている

> onig_init();
については947自身で答えが出てるのでよしとして、

> それが使われているのではないか」という仮説を立てています
結局の所、新しくコンパイルしたdllが使われてるか断定出来ないからだと思うが、
上記の通り、エラー吐いてる箇所(＝そこを通ってると確実に言える場所)にfprintf仕込んでしまえば、
fprintf出力されれば、新しくコンパイルした物、そうでなければ古いまま、と断定出来る
とはいえ他のかなり高級な方法
> oniguruma 6.9.9 で Fix されたバグが直っているのを確認しました
で解決したのでよしだが

> このテストファイルのコ-ドを php_mbregex.c に移植して動かしてみました
これは php側のコンパイル環境も立ち上げたって事？
ならfprintfはphp側にも仕込めるようになるが、あまり手を広げすぎても収拾付かなくなるから、
とりあえず上記oniguruma側でfprintf仕込んで何を検索しようとして失敗してるのか確認した方がいいと思う
(※なおやらなくても見当付いたが)
少なくともoniguruma単体で動かせるのなら、
どういう正規表現を与えたら何を登録/検索してるかは確実に引き出せるし、
同じ正規表現をphpから与えた場合と比較も出来るし

まあ、でも一旦956,959で回避するのもありよ
好きな方でどうぞ

ちなもうちょっといけるかと思って 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
が引っかかるのだが何ぞこれ？

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" *
mbstring>grep -n -r "SKIP\\W" *　は共にまさかのヒット無し
mbstring>grep -n -r FAIL *
mbstring>grep -n -r SKIP *　を共に確認するも、無い
php-8.3.12\ext\mbstring>grep -n -r "FAIL\W" *
php-8.3.12\ext\mbstring>grep -n -r "SKIP\W" *　で同様にphp側も確認するが、無い

つまり、(*SKIP)(*FAIL)自体の定義が見あたらない
仕方ないので callout_name_find から onig_st_lookup_callout_name_table を辿ると、onig_st_lookup を呼んでいる
ところがこれも定義が見あたらない
まあCの場合はマクロで相当な事が出来るのでよくよく探してみれば出てくるかもだが

なのでこちらは、現状、
・(*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 の定義部分

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

ごめん間違ってた(>>11)

×　> mbstring>grep -n -r FAIL *
○ > oniguruma>grep -n -r FAIL * のつもりが、やってなかった

やればぞろぞろ出てきたので、また続き報告します

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)の文字列から検索出来てないだけ

ありがとうございます、規制に引っかかったのでとりあえずこちらに書きました
2chb.net/r/mango/1715675838/333

向こうにも書きましたがもう調べて頂かなくて大丈夫です、すみません..

同様に 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の正規表現のエンコ
ードが異なってて検索失敗かと
ありがちなのは、'SKIP'を
php:utf8で 0x53,0x4b,0x49,0x50 と送信
oniguruma: utf-16LEで、0x53,0x00,0x4b,0x00,0x49,0x00,0x50,0x00 を期待
とかで検索ミスかと

多分onigurumaをコンパイルする際に『phpとやりとりする』（＝APIの)正規表現の文字エンコ
ードを決められる
多分コンパイルオプションにあるから確認してみて
なおこれは対象文字列のエンコ
ードとは違うので注意
phpで言うと、
mb_ereg_replace(
string $pattern, <- 今問題になってるエンコ
ードはこれと
string $replacement, <- これ
string $string, <- onigurumaが様々なエンコ
ードに対応出来てる、というのはこれ
?string $options = null
)

実際のエンコ
ードを確認したければ、fprintf を仕込めばいい
面倒ならありがちなのを(といってもほぼutf-8のはずだが)全部試して動く奴を探してもいい
既に書いてるが、多分 utf-8(php)とutf-16(oniguruma)で空振りしてると予想
よろしく頑張ってちょ

(※2): シングルクオートになってるのはdos窓だとイマイチ動かなかったのでunix環境(cygwin)に切り替えたから
　多分知ってるだろうから問題ないと思うが、意味無いところで疑問に思われても無駄なので念のため

>>15
了解、今から読む
とりあえず書いたので全部落としておく

>>15
読んだ
> あなたのような優秀な方を空回りさせてしまうのは申し訳無さすぎますので..
これは気にする必要ない
俺は「たまには他人のコードも読むべき」と認識してるから、機会見つけて読んでるだけ
一人で読んでても仕様とか知らんしハマるので、他人がいるときに合わせて読んでるだけだから
実際君はかなり仕様を知ってるし、結果的に辿りやすくなってる

> oniguruma には自分で任意の (*hoge) を作って oniguruma に登録することが
> 出来るという機能があります
あーやっぱこれ目当てですか

> そこで php_mbregex.c の中で任意の (*hoge) を作って oniguruma に登録し、
> test.php を実行して任意の (*hoge) が正規表現のパーツとして認識されるか
> どうかを確認したところ、ちゃんと認識されました
さらっと書いてるけどこれは結構ハードル高いはず、まあ動いたのならすごいが

> なので、(*hoge) の名前が文字化けして見つからないという訳ではなさそうです
orz、ハズレか…

> PHPでこの機能が使えているということは FAIL や SKIP も自前で
> 登録し直して使うことが出来るようになるかも知れません
まあ既に動いているのなら行けるはずではあるが、本来は書くのはエグいはず
コピペで移植してしまえであれば、
src/regint.h:989 の辺りから定義をコピペして php_mbreegxをコンパイルしてしまえば
php_mbregexがonigurumaとのキメラになるが動けば使えるはず

まあ頑張ってちょ

ぶっちゃけ理解が全然追いついてないので明日またじっくり読ませて頂きますね
今日はありがとうございました

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

ここが問題の核心ですね、どんなラスボスが潜んでいるのやら..

また規制のためこちらへ
2chb.net/r/mango/1715675838/334-335n

昨日のレス把握完了です、これからお返事書きます(時間かかるかもです)

phperですがjsp＋java案件に入りました
直近の課題として、phpとの差異に四苦八苦してます

まず大きな問題としては、今までほぼ手続き型のphpしか触っていなかったのでオブジェクト指向でのJavaに苦戦してること（今まではユーザー定義関数群を1ファイル内に記述して適宜各画面で読み込んでいたに過ぎず、継承やclass・フィールド・メソッドといった経験をしてこなかったこと）

次いで、jsp→サーブレットの仕組みや処理の流れを落とし込めていないこと。jspそのものはphpファイルのようにスクリプトを埋め込めることは理解しましたが、コンパイルや、そしてサーブレットに渡してゴニョゴニョするんやで❤の辺りから頭から煙出てます。

次いで、Javaとphpの記述の違いに悩んでる事。例として文字列の比較や、型宣言など。

諸先輩方はどんな風にして他言語をphp基準に身につけたか、そのほか叱咤激励あれば教えて欲しく投稿しました

ちなみに前スレからのonigurumaのやり取りは見させてもらっていてとても有益な内容のやり取りだと感じてます

その上で「このスレなら頼りになる人が居るぞ！」や「皆はどんな風にしてphpから他言語を学んでいったのか」という情報交換が出来そうなので投稿しました。

不躾で恐れ入りますが何卒宜しくお願い致します

あ、私の件はもう解決したと言って良い状態なのでお構いなく..
私より >>23 さんを優先してあげてください、ありがとうございました～

コマンドラインに現在時刻を出力するプログラムで(Windows+cmd)

while(1){
echo date('H:i:s').PHP_EOL;
sleep(1);
}

これだと改行して延々と表示されます
改行せずに1行で更新し続けたいときはどうすればいいですか？
なんか制御文字入れたら出来たような気がするのですが忘れてしまいました

私は>23ですが、こんなのどうでしょう
コードベタ書きは書き込み制限あるので一部ホワイトスペース入れたりお茶濁してるので適宜変換したください

①
while (1) {
echo "\r" . date('H:i:s');
sleep(1);
}


②
while (1) {
echo date('H:i:s')."\r";
flush();
sleep(1);
}


やってる事はほぼ同じですが、お役に立てれば嬉しいです

>>26
確認できました！どうもありがとうございます
DELあたりが怪しいと0x08をどうにかしたら…
なんて思ってましたが見当違いだったようで(ﾉ∀`)

>27
解決できたようで良かったです！
もしJava経験あれば私>23なのでアドバイスください！笑

NGスレ06 にお返事を書いてましたが連投規制なのか続きを書けなくなりました
2chb.net/r/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さん！！！

EOLの意味を理解しているのか聞いてみたい

clsコマンドでもいけそう、以前のログ全部消えるけどｗ
linuxfan.info/clear-command-prompt

End Of Life

エターナル オオイタ ライフ

変数名ってなんでローマ字は駄目って言われるんですか？
日本人しか触らない日本のシステムなんだからわざわざ英語名にしなくても日本人全員が理解できるローマ字でいいと思うんですが
ましてやドメインに関わるものなら固有名詞に近いものまであるのにローマ字でなく英語にこだわる理由が分かりません
現場のリーダーに同じことを聞いたらローマ字だと問題あるかもしれないからと言われてそれ以上は聞けませんでした

大人になったらわかるよ

長い表記で更に人目でわかりにくいしデメリットしかなくない？

日本人なのになんで分かりにくいローマ字を使うのだ
分かりやすくするなら漢字と平仮名とカタカナを使いたまえ

ちなみにonigurumaはメタ文字として使う文字を好きに変えられるのだが
試しに \ の代わりに ゑ にしたらちゃんと動いたよ
日本語で書く正規表現が作れそうでwktk

>34
ローマ字記法（ヘボン式・日本式・訓令式）の事かな？結露から言うと、その命名規則にしてる現場もあるよ。特にレガシーな業務システム（2000年から2010年辺り）の現場で多い。例えばh o s y u U n y o（保守運用）とかs y a i n B a n g o u（社員番号）とか。

問題点と言えば、
・現場でしか使用されていない特殊な専門用語や業務用語を変数名にすると引き継いだプログラマーは初見で変数の意味を理解できない
・記述が長くなる
・ヘボン式や日本式の違いで誤記が発生する。例として社員なら　s h a i n、s y a i n など
・英語話者プログラマーが読めない
・エディタのコード補完機能が使えない。多くのエディタは汎用的な命名の予測変換や補完を行ってくれるため。

>34 一般的にプログラムはチームで書くことが多くて、「誰が見ても分かる」が原則。この「誰が見ても分かる」がポイントで、もし内輪だけで使うプログラムならローマ字表記でも良いと思う。一方で、プログラマーが入れ替わる現場や英 語話者の居るグローバルなチームならローマ字表記不可。

他の理由には、開発されたプログラムそのものも大概は英 語圏で作られている。その為変数や定数の命名もベースは英 語圏から発生していて、その命名は汎用的に使用できるようになってる。よって上記同様、ローマ字表記法は汎用的ではない。

最後の理由としてプログラムは様々な箇所で引用される。作成されたプログラムが信頼に足りる素晴らしい内容なら、多方面で引用され関数やメソッドやA P Iとして汎用される。そのため英 語話者が読んで意味が通じないならそれはプログラムとしては良くてもソースコ ー ドとして通じない。 こんなところでしょうかねー。早い話オープン ソースにしようものならローマ字表記法は絶対出来ないですしねw 逆に1人だけで使うプログラムとか、内輪だけの限られた世界でしか使用しないプログラムならローマ字表記でも良いと思いますよ。

一番最悪なのはローマ字でファイルやクラス設定して途中から名称変わったせいでどのクラス参照して良いんだかわからなくなるパターン

aiに聞いたほうがはやい

次回、

「ヘボン式至上主義者と訓令式至上主義者の仁義なきソース手直しバトル」

ご期待下さい

異常を ijo と ijou のどちらにするかも悩ましいですよ

(ご報告) Oniguruma の 'SYNTAX.md' の件

以下の通り、'SYNTAX.md' の更新が一応完了したのでお知らせです

github.com/kkos/oniguruma/blob/master/doc/SYNTAX.md
github.com/kkos/oniguruma/blob/master/doc/onig_syn_md.c

Print the table in 'SYNTAX.md'
github.com/kkos/oniguruma/issues/315

私のスキルがショボいせいで中途半端な出来になっており、作者様には申し訳ないです..
onigurumaの新しいリリースに間に合うようにと考えて現時点のものを取り込んで頂きました

あとは 'SYNTAX.md' の「Set in」を自動で書き換えるプログラムですが、これは自分用の
pythonプログラムは既に作ってあるものの、やっつけで作ったものなので公開する
レベルにありません いつかちゃんとしたものを作って公開出来たらなと考えています
それまでは自分が自分用プログラムで書き換えれば良いかなと..

ということでご報告でした、皆様ありがとうございました～ onigurumaの作者様にも感謝です

完成させるだけでも立派よ

そう言って頂けると嬉しいです、ありがとうございました

私はC言語を知らず、動的なメモリ確保やsprintfなどを使えなかったのですが、
それらを使わなくても作れるプログラムだったのはラッキーでした^-^

Oniguruma の (*SKIP) が正式に使えるようになりました
https://github.com/kkos/oniguruma/releases/tag/v6.9.10

元旦にでっかいお年玉ありがとうございます > 作者様

規制テスト

開発終了の理由は Oniguruma#349 です。 最後のコメントをご覧ください。
Oniguruma#351 は Oniguruma の fix_351_349 ブランチでのみ解決済です。

Oniguruma#351で解決した問題
github.com/kkos/oniguruma/issues/290#issuecomment-1805754012

Oniguruma#351で解決した問題の原因
github.com/kkos/oniguruma/issues/290#issuecomment-1825555154

個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチ を取り込むことをおすすめします。
上記の通り、ユーザーを困らせる問題が１つ解消されるからです。

しかし、この修正は正規表現の仕様変更です。正規表現の動作が変わってしまいます。
しかしその影響を受けるケースはごくわずかであり、ほとんどのユーザーにとっては不可思議なエラーが
出なくなることのほうが重要だと思います。
------------
PHP で ONIG_SYNTAX_ONIGURUMA を使えるようにする方法。このスレの(*SKIP)の話のまとめです。
github.com/tonco-miyazawa/PHP_syntax_oniguruma

現在の PHP では ONIG_SYNTAX_ONIGURUMA を選択出来ません。

>>49
お疲れ。#290,#350,#351は読んだ。
相変わらず君はまともだね。正しく議論も出来ているし。
昨今の馬鹿ばかり無限に湧いてくる5chに辟易してる俺にはかなりの驚きだ。
(ただしこれは誰が悪いというわけではなく、俺が今更「永遠の９月」を追体験してるだけではあるが。
参考: https://ja.wikipedia.org/wiki/永遠の9月)

> 個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチ を取り込むことをおすすめします。
PHPは互換重視、というより、互換絶対、だ。だから厳しいだろう。
(いうて最近はコンテナにぶち込んでさようなら、というのもありのようなので、
互換性の問題を仮想化で解決したとも言え、問題ないのかもしれんが)

界隈の状況全く知らんが、普通に考えて、
・特に問題ない場合(＝互換性が保たれている場合)、最新リリースを取り込む
・最新リリースでbreaking changeされており、互換性を保ったリリースの提供が今後もされない見込みの場合、
　・しばらくは現行バージョンを使い続ける
　・メンテ可能であればフォークしてPHP専用onigurumaにしてしまう
　・諦めて別エンジンに乗り換える
　の順だと思う。

(実際どうなのかは確認してないが)、一番可能性のあるパターンは、
fix_351_349は一時的な解決策として動作確認の為のリリースであり、
問題なければ、最終的に正式ブランチに「何らかの動作モードで切り替えられる」形式でマージされる。(例: (https://github.com/kkos/oniguruma/issues/351#issuecomment-2816719627 内 \U)
そしてPHPは php_mbstring.c 内でそれを互換モード(＝非fix_351_349モード)に固定して取り込む、といったところか。
だから君はこうなるよう、つまり、
・fix_351_349が希望通りの動作をすることをを確かめ、
・正式ブランチに何らかのフラグで切り替えられる形式でマージされ、
・自分の php_mbstring.c 内でそれをfix_351_349に固定してしまうか、
　PHP側からフラグ与えられるように書き換え、プルリク出す
方向で行動すればいい。
(あるいはコンテナがあるから最早互換性なんて必要ないです！！！というキャンペーンもありなのか？)

ただ
> I would consider changing the spec to not match different number of characters with flag i.
なのは下手すると今後は互換バージョンは提供されないのか？
なら前述のとおり、しばらく様子見され、その後は不明だね。
(後述するが、現時点ではこの判断は間違いのように見える)

…と思っていたが、昨日mergeしたのか？
(まあ実は俺はGitHubはほぼ使ってないのでissueのアイコン見ても何が何だか分からないのだが)
breaking change したのなら、決定が拙速すぎる気はする。
少なくともユーザー界隈、つまりPHP,Ruby,VSCode界隈に打診して反応聞いたほうが良い気が。
まあこれからフラグ付加すりゃいいだけという話かもしれんが。

breaking changeは結局、
・これまで書いたコード
・これから書くコード
のどちらを優先するか、でしかない。

ちなみにRubyが死んだのはこの辺の判断を間違ったためだと思ってる。
2012年のRubyカンファレンスだか何かで、
・互換性を重視してこの仕様にしました！！！ ← ウォー！！！
とか盛り上がってたらしいが、そりゃそこに居る連中は「既に書いてる」奴だから、互換重視の方がウケるのは当たり前。
存続するためには「ご新規さん」を取り込むことが必要で、
当然彼らに魅力的なよう、くだらない仕様は修正していく必要がある。
丁度この時期にRuby界隈でそこそこ頑張ってたやつがイマイチな仕様を修正しようとしてて、(確か%sだったか)
結果的に互換重視の決定となり、「俺の影響力なんて皆無だと知ったぜ…」てなボヤキをしてた。
単純には、breaking change は既存ユーザーを減らし、新規ユーザーを増やす方向に圧力がかかるので、
界隈の状況を見つつ、結果的にユーザー総数が増える方向に舵切りするのが正しい。
だから言語の前半期(成長期)はbreaking change を恐れず積極的に問題を修正し、
後半期(安定期)には互換性重視で既存コードを守るべきで、
つまりこの意味ではRubyは2012年に後半期に入る宣言したとも言え、実際その辺からだだ下がりで現在がある。

してPHPは、というと、どう考えても既に後半期に入っている。
だから互換性は絶対で、それ以前にそもそもONIGURUMAモードすら使えてないし、おそらく今後ともしばらく使えないのでは？
これには後述するが、PCRE程度でいいや、という考えもあるのではないかと思う。

ついでに、前回結果的に投稿しなかった内容も書いておく。
(というか、中途半端には書いたが、全部書ききるのが面倒で、とりあえず結果も出たようだし、まあいいか、になってしまった)
PHPではなくほぼ正規表現とonigurumaの話なので、PHPにしか興味ない人は読む必要はない。
以後続くようならスレは移動してもいい。
俺はIP表示がなければどこでも可(ワッチョイも問題なし)なので、
別スレに落とされたレスがあれば、それに対するレスはそこに落とす。

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

> 速度面での恩恵が大きい (http://2chb.net/r/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の言う「実装が仕様にはみ出している」から。
つまり、今回も、あるいはバックトラックの理解/制御が必要なのも、「遅い」からであって、
十分速ければこの必要もないし、ユーザーもバックトラックなんて理解したいわけではなく、正規表現を使いたいだけだから、と考える。
富豪プログラミング万歳！！！ってところだ。

とはいえ、現実的に無理だからαという判断なのだと思うし、実際この方向の需要も確実にあるのも事実。
例えば
A. preg_match('/OK|NG/', ... よりも、
B. if ($str[i]==='O' && $str[i+1]==='K' || $str[i]==='N' && $str[i+1]==='G') ...
の方が(PHPでは微妙だが、少なくともCでは)速いのは確実だが、
正規表現の方が読みやすさが格段に上なので、if文だと将来的にメンテコストが上がる。
(この辺しょうもないと思うかもしれないが、Aだと見た瞬間理解《所要0.5秒》に対し、
Bだと読まないと理解できないので《所要5秒》、長期的に大規模なコードをメンテする場合はかなり問題になる。
まあこの例だと簡単すぎてイマイチだが、もっと複雑な文字列検索をif文で書くとだいぶ酷いことになる)
この為、if文記述が最速と分かっていても、正規表現『的な』、見た瞬間分かる記述で書きたい需要はある。
そしてこれをオレオレライブラリ化しても、仕様自体は正規表現的なものになってしまうので、
なら、正規表現の仕様として追加し、正規表現エンジンにやらせる、というのは、非常にもっともな解ではある。
そしてこの方向を向いているのがonigurumaではある。

ただし俺として最高なのは、Aのソース記述をコンパイル段階でBにして最速化する、であって、
つまり全自動での最適化を望んでる。手動で手間かけてまでやりたくない。
この場合に必要なのは「明示的な『任意の最適化の許可』フラグ」だ。
これはつまり、現在 retry-limit-in-match over 等で落ちてる正規表現に対し、
「任意の最適化の許可」フラグを付ければ、「通る『事がある』」という、なんとも微妙な方向で、
制御して確実に動作させきるという、αな「正道派」からすると許容できない仕様ではある。
ただ俺は「結果が正しく、十分速ければ、何も問題ない」という、大半の、βな「ライトユーザー」的な発想であり、
バックトラックの制御なんてしたいとは全く思ってない。
ただし、問題になる箇所が後々でもすぐ分かるように、「明示的に」フラグを付ける。
結果、以後はそのフラグが付いた正規表現だけを気にしていればいい、それ以外は確実に動く、といった所。
(フラグが付いてないところはこれまでどおりの仕様で動く。
つまり、現行の動作で retry-limit-in-match over 等で落ちず、今後とも互換で同様なら、同様に落ちないことが保証される)
ある意味、「現在」確実に動かすよりも、「将来」的にメンテナンス性を上げることを優先してる。
これは上記のif文と同様、バックトラック制御を駆使して事細かに書いてる正規表現は、
単純な正規表現と比べて読むのに時間がかかるので、
バックトラック制御を追加したら同様の結果を速く得られると分かっていても、
特に問題ない箇所はできるだけ単純な記述を使うべき、とする考えになる。
《ちなみに逆の考え方は、バックトラック制御等が付加されてる程度の正規表現は一瞬で読めるように鍛えろ、となる。
あるいはBのif文記述の読み込み速度を上げろ、もありか》)

そして一般的には、プログラマはα方向、非プログラマはβ方向を好む。
これは、プログラマは論理的理解をしてでも確実に制御しきりたいのと、
そもそもプログラマはソースコード内に記述して使うことが大前提のため、
読む回数>>>書く回数、というか、読むことに費やす時間>>>書くことに費やす時間、となるから。
だから、プログラマにとっては、多少冗長でも、すぐ読める記述のほうが好まれる。
逆に非プログラマは、まあ俺の偏見でもあるのだろうが、例えば昔に5chの正規表現スレにも書き込んだことがあるが、
かなりアウェイ感、というか、見解の相違を感じた。
どうやら連中はブラウザや蔵書検索エンジン等の「検索窓」で正規表現を使うことが主目的らしく、
基本的に正規表現はその場で使い捨て、つまり、書く時間>>>読む時間、なのだな。
だから、凄まじく記号化して、結果的に1文字でもタイプ数を減らす方を好むようだ。

等々、色々な点で大前提が違うので、プログラム板以外ではだいたい俺はアウェイで、
色々酷いことになってるが、まあそれも含めて楽しんでる。
そして上記の5chの正規表現スレ、どうやらonigurumaの連中の巣窟だったようで、
当然のごとくPCREと覇権争いをしてて勝つのはonigurumaだ、みたいな奴らだった。
俺的には、速く動けば何でもいいので、勝手にやってろ糞ウゼーとしか感じず、
よって、俺はそもそもoniguruma連中にいい感情を持ってない。
まあこれは君がここで質問するだいぶ前の事だが。

とはいえ、VSCodeにもonigurumaが入ってるらしいので、連中が順調に成長してるのは事実だ。
もしかするとRuby以上にいい線行ってるかも、とも思う。
とはいえ、αの方向はどうなの？とはかなり疑問ではある。
現行の先読み/後読み等もそれなりにややこしいので、
そもそも論理的理解力が乏しい非プログラマ連中にはかなり向いてない。
結果、現在もいるであろう、「正規表現だけしか出来ない馬鹿」を余計にのさばらせるだけではある。

まあこれに関しては余談になるが、
ずいぶん昔にコメントアウトの　/* */ を正規表現で削除する処理する、というブログページがあって、(とはいえ今検索しても出てこないんだが)
曰く、単純に preg_replace するだけでは、内部に任意のコメントを書かれたときに対応出来ない、
だからコメントとしてこういう文字列を書かれた場合に対応するためにこう、そしてこう、、、、と続き、
最終的にこれだ！！！これで何をコメントされても完璧に動く！！！
というのがあって、この程度書けないようなやつは困る(ｷﾘｯ、みたいな締めになっていたが、
うむ、なるほど、俺には読めんな、とは思った。(結果忘れてここに書けないのはすまん)
しかしこれ、そもそもコメント /* */ なんて正規表現以前の時代の産物で、
当然その時代のコンパイラでも問題なく処理できる仕様となっており、
実際、whileとif文でなら(面倒ではあるが)馬鹿みたいに簡単に書ける。
だから、プログラマには「whileとif文で書く」というオプションがあり、
(あるいは、被検索文字列を前処理したり、正規表現処理を複数回に分けたり等の、プログラムを書く事も可能)
結果的に正規表現を極めきる必要はなく、
世間と同程度の正規表現を読み書き出来ればまあ問題ない。
この点、「検索窓」ではどうにもならないので、非プログラマは何がなんでも「正規表現で一撃で済ませる」必要があり、
結果的に正規表現を極める奴が出てきて、
そいつらからすると俺らプログラマはなんとも中途半端な理解に見えるようだ。

結果、「プログラマ」連中は、ソースコードに書かれてる程度の正規表現は読める必要があるが、
過度な正規表現は他のプログラマが読めないので禁止であり、中庸の正規表現の使用に落ち着く。(これがPCRE程度、というのが多分一つの目安)
非プログラマ連中は、極めた「匠」となり、なんでも正規表現でやり切るか、
「正規表現書けるの？すごーい！！！」程度の「ウルトラライト」に二極化する。(勿論断然多いのは後者)
なので、α方向は実際どうなのよ？はかなり疑問である。
現実的に現在のPCREな正規表現だと色々足りてないのは事実だが、
onigurumaなバックトラック制御を今後もてんこ盛りな方向だと、
結局読みにくい(＝読むのに数十秒かかる)正規表現になってしまう気もする。
プログラマ的には、正規表現と、if文と、読みやすい方を選べばいいだけではあるので、使わなければいい、ではあるが。
ただ件のスレのoniguruma連中は、「匠」なので、α一択なのだろうけど。
俺としては、つべこべ言わず動けばいいだけなので、問題になってる正規表現にだけ明示的に「任意の最適化の許可」付けて、
結果的に動作し、バックトラック制御なんてしなくて済むほうが助かるが。

さて読んでて思ったのだが、これ、仕様が矛盾してて、現実的に実装できない可能性も有るのでは？
これは当人も気づいてて言及してるが、実際に矛盾してるかどうかまでは分からないようだ。
> 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から検索すると存在せず、あれ？ってなったことがあった。

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

例えば典型的な糞ッタレ正規表現、
> 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で右から検索すれば多分最速になる。
この辺、バックトラックの指定を事細かく出来る＝走査順が仕様として規定されてしまう＝左から右に走査、となってしまってるのが問題なので、
「任意の最適化の許可」フラグで、右から左に走査することも許可し、(勿論それ以外にもやっていい)
結果的にクソ速いがバックトラック制御は出来ませんよ、が正しい気がする。
(フラグ指定した場合、どう走査されるかはエンジン任せで、
結果的にバックトラック制御を指定してもどう動くか予想できず、実質使えなくなる。
が、問題は速度が遅いことであり、バックトラック制御をするのが目的ではないのでこれでいいはず)

ちょっと伝わりにくいだろうからもう一度書いておくと、俺の希望としては、
プログラマがコードとして書くのは(a)で、
これを内部的に(c)で処理して最速化しろ、
処理順だけ書けば(d)になるが、この正規表現では読むのに時間がかかる(所要30秒)ので無理、
「匠」は(b)を書くが、これは(a)よりは理解に時間がかかる(所要10秒)し実行速度も最速ではない。
「プログラマ」は(a)で無理なら最速の(c)プログラムを書くが、
(a)は2秒で理解出来るのに対して、
(c)見て(a)と理解するには1分かかるので、前述のとおり、これをプログラム全域にまぶすと後々詰む。
最低限、(c)の先頭行に、// /a.*b.*c.*d.*e/ を高速化した とコメントがないと死ねる。
しかし結局、(a)の処理が速ければ最初から何も問題ないので、目指す仕様はここで、内部的に頑張ってくれ、という事。
ユーザーに「匠」となり、最適な正規表現を精巧に作り上げることを要求するのではなくてね。
(だから仕様追加するなら「後ろから検索」フラグ、でもいい。
そして /e.*?d.*?c.*?b.?a/Backwards で(a)と同様の結果が得られるとかでも)

とにかく、ユーザーが困っているのは「仕様」ではなく「実行速度」なのだから、
それを「仕様」の限定化(仕様縮小＝スペックダウン)で回避するのは悪手であり、まず高速化をやるのが先だ。
あるいは \U のように、unicode対策を外すフラグ付加（＝フラグ付加時のみ仕様縮小での高速化)で対応できる。
kkos氏はこの仕様が実行速度に多大な影響を及ぼしているのを知っており、元々外したいと思ってたのだろうがね。
しかし、この状況で「仕様」を変更するのは、一般論としては明確な間違いだ。
何度も言ってるが、今の仕様は正しいので。
(とはいえ、結局この辺の采配、つまり理想と現実の兼ね合いでどう仕様を決めていくかが最終的な繁栄/衰退につながるので、
勿論kkos氏が決めるべきだし、実際、この仕様を捨てたら爆速化して更に支持率ダダ上がり、の可能性もある。
まあこの辺の采配を間違えたのがRubyと見てるが、onigurumaは果たしてどうなるか、といった所)

> Therefore, choices for elements other than the character class are generated after the character class.
ちなみにこの意味が分からない。(が、#350にもそのまま転載されてるから彼らの中では通じてるのだとは思う)
これって具体的にどういう意味か分かる？
/(?i)[\S]/ を
/(?-i)(?:s|t|st|ss)/　ではなく、
/(?-i)(?:ss|st|s|t)/ (greedyなので長いほうが先、ついでにアルファベット順でssの方が先)
と見なす(に近い)ということか？

以下 https://github.com/kkos/oniguruma/issues/351#issue-3005666017 内について
> [r`(?i)^[\w]$`, 'ss'], // ✅
> [r`(?i)^[^\W]$`, 'ss'], // ❌ ←　むしろこれがアウトだろ、疑問マーク付いてないが
>
> // The negation rule is about negation of the outermost class, only 🤔 ←　この解釈が間違いで、
> [r`(?i)^[[^\W]]$`, 'ss'], // ✅ 🤯　←　これと
> [r`(?i)^[\w&&[^\W]]$`, 'ss'], // ✅ 🤯　←　これには俺は問題を感じない
> // In the reverse direction with quantifiers; nothing surprising here　←　いや、
> [r`(?i)^s{2}$`, 'ß'], // ❌　← これはヒットするべきでは？
と思うが、まあこの辺は互換性もあり、なかなか変更できないのだとは思う。

以降は前回の話について
(途中まで書いてたのに付け足してるので時系列的にちぐはぐかもだが。
あと若干、何まで書いたのか忘れてるので、重複も有るかも？)

> 名前が見つからずにエラーになる原因は oniguruma に "FAIL" や
> "SKIP" などが登録される前に callout_name_find されているのが原因でした
つまりonigurumaの「登録」(初期化ルーチン)と「検索」(phpのmb_ereg_replace)が
レーシングしていて(通常「競合」と訳されてるようだが、個人的には「競争」と訳すべきだと思っている)
fprintfのおかげで偶々運良く上手く行く方向に変わったわけだ。
(まあ一般的にレーシングの場合は再現性が低い＝ちょっと条件を変えたらすぐ収まってしまうので、こういうこともよくある。後述)

> C言語のことを知りたいなら本なりで基礎から学ばないとダメですね
そうだが、実際の所、何となく読めるはず。
理由は簡単で、C言語は現在のメジャー言語全部の下敷きになっており、
文法はメジャー言語から見ればスモールセットでしかないから。
実際学んでも、ifとforとwhileだけですかー、と何も無さ過ぎてビビるはず。
ただしポインタを生で使える点だけが違う。
(とはいえphpでも全容を把握する為にはポインタの理解はある程度必要なので、
逆に言えばphpを完全理解してるのなら《知識的な》修得自体は容易。
phpで言うと、配列を「値渡し」して関数内で変更しても、元の配列は変更されないので、
変更したい場合は「参照渡し」しなさい、となってるが、その辺)

C言語は基本的に一対一でアセンブラに落ちるので、高級アセンブラのようなものではある。
だからC言語はCPUの動作そのものに近く、プログラミングにおいてはベースの前提知識として役立つ。
結果、どの言語を学ぶにしても見通しがよくなり、修得が早くなる。
だから職業プログラマを目指すなら、できるだけ早い段階でやっておいた方がいいし、
実際、大学のCS系では今でも1年生の時期にやってるはず。
何だかんだでベースの前提知識として役立つ。

というのを11月に思ってたのだが、(特定する気もないので該当するかどうかを答える必要はないが)
もし君が学生で、職業プログラマを目指しているのなら、今すぐにでもCをやるべきだ。
理由は上記のとおり、上達速度が上がるから。
なんかね、君の「知識/経験」と「能力/実力」のアンバランスさが異常で、正直俺は遭遇した事がないレベル。
「やってみたら出来ちゃった」的に話が進んで行ってるのが異常で、
普通は知らない言語の時点で諦めるし、勿論環境も立ち上げない。
こういうの無視して闇雲に突撃したところで成果も出ない。
ある程度年取って「分別のある」プログラマなら、この辺知ってるから、突撃もしない。
だから無鉄砲に突っ込んで結果まで出してるのはかなりありえない展開で、
俺が思いつくのは、あまりにも若すぎて、自分の実力を認識できてない、とかだね。
まあスポーツ選手にしろアーティストにしろ20代そこそこで世界に駆け上がっていくので、
本当に実力のある若者はこんなものなのかな？程度に思ってる。
君は俺のアシストが効いたと思ってるのだろうが、そうじゃない、それは明らかに君の実力だ。
確かに今回はラッキーもあったが、GitHubでまともに議論参加できてるし、実力の片鱗は見えまくり、といった所。

ただし、C言語の「理解」が目的で、C言語を「極める」必要はないことに留意すること。
C言語が50年も現役で居続けられるのは仕様/構成が素晴らしいからであり、この理由を理解するのは重要だが、
今C言語を書く必要がなければ、達人である必要はなく、当然書ける必要もない、
というか、Cにも問題が多々あったから、Cをベースとして他言語が発達してて、
つまりCの駄目なところは他言語使えばだいたい解決してる。だからCを書くこと自体に苦労する必要はない。
ただし、どういう思想でどういうコードを要求してる言語なのかを理解することは本当に重要。
まあこれでは分かりにくいので一つ例を上げると、「ポインタ」になる。
「ポインタ」の概念を理解できてて、他言語でも、ああこれは「ポインタ」だね、と分かることはかなり重要。
ただし、「ポインタ」を使いこなして、素晴らしいCコードを書ける必要はない、という事。
まあ「ポインタ」はよく言われるけど、その他も、例えば変数のライフタイムとかうまく出来ており、
Cの仕様は、「確かにこれしかない」と思えるものなので、無駄のないコードをどう書くかの参考にはかなりなる。

さて話を戻すと、onigurumaはC界隈でもあまりやってはいけないとされている「マクロ芸」をやってる。
だからCマクロを知らないと読めないが、これはoniguruma側の問題だ。
(なおC++ではCの問題はCマクロで色々誤魔化せる事だとし、
Cマクロが使われる状況毎にC++文法を用意し、これを使う事でCマクロの除去を目指している。
だからC++ではCマクロは禁忌とされてる。
《と言っても『当初の』C++は、で、その後明後日の方向に暴走してたが》)

Cマクロは「ソースコードを直接書き換える」ので強力だが、結果、
「プログラマが見てるコード」とコンパイラで「実際に使用されるコード」が異なる事が大問題だとされてる。
なので、注意喚起、つまり、
「お前が今見てるコードと実際使われるコードは『別物だ』」と
『見た瞬間』分かるように全部大文字で書け、とされている。
だから小文字マクロは可読性の意味では完全にアウト。
(といってもLinuxコードには使われまくってるのだが、
あれはこういう決まり事が出来る前の産物だし、
また、小文字マクロでも可読性を損なってないのも凄いのだが)

onigurumaで小文字マクロが大量に使われてるのは、おそらく大改修中だからだ。
全部大文字マクロに変更して変更箇所が膨大になるよりは、小文字のままで行ったほうが混乱しないと踏んだのだろう。
そして今回は初期化ルーチンのレーシングだが、こうなったのは仕様が変更されたから。
単体のonigurumaの使い方は分からんが、PHPで言うと、

当初：CGIで、毎回PHPを起動しては全部捨てる(各PHP毎にonig_initを呼ぶ)
今：モジュールで、一度PHPを起動したら常駐(初回にonig_initializeを呼んで以降は呼ばない)

レーシングしてたのは改修中で整合性取れてなかったのか、単に変更忘れててバグってたか知らんが。
そして条件を変えたら直ってしまった、というのは運だが、そこから追跡して原因まで到達してるのだから順当に実力だ。
ただもっと運が良ければ、例えばlaravelとか使ってたら、最初から動いていたかもだが。
つまり、レーシング自体はかなり微妙な場合も多い為、
mb_xxxxを呼ぶ前にlaravelのコードを大量に処理すると、これだけで動く方に倒れてたかもしれない、ということ。
ただこの場合、再現性が低くなり、（＝俺の環境では問題ないが続出、あるいはlaravelのバージョン毎に出たり出なかったり)
デバッグには相当手こずるので、
まあ状況不明だが、デバッグ出来たのは、kkos氏にとっても意味はかなり大きいとは思う。

あとちなみに、(*FAIL)が辞書にない＝(*FAIL)も辞書登録する、ということであって、
つまりonigurumaは(*FAIL)もユーザーが動作を上書きできるようにしてる。
普通はこの辺はリテラルで与えるので、登録されてねえ…ってことには構造的にならないんだけどね。
まあこの辺はkkos氏のポリシーなんだろう。


てな感じ。まあぶっちゃけだいぶ忘れちゃってるのを色々覚えで書いてるし、どこまで投稿したかも忘れてるので、
重複があったり、間違ってたらごめん。

補足

実際にコンパイラ/インタプリタの実処理系で
「特定の文字列が含まれたソースコードは開けない/動かない」なんてことは聞いたことがないので、
これらでは仕様策定時の想定通り、if文で処理してる。
だからシンタックスハイライターで正規表現を使うのは手抜きでしかないが、
>>57の通り、この手抜きをやって新しい文法により早く対応することを優先するのは正しい。
(全部if文で書け、なんて言われたらシンタックスハイライターをメンテするやつが居なくなる)


>>61は、
✕ 内部に任意のコメントを書かれたときに
○ コメントを書かれるあらゆる状況に
だったかも。/*が''等で囲まれてる場合には単純に/* */を除去しても駄目。

echo '/*aaa*/'.''/*bbb*/.''; // PHP: /*aaa*/
console.log('/*aaa*/'+''/*bbb*/); // JS: /*aaa*/

>>63-66
仕様変更は https://github.com/kkos/oniguruma/issues/351#issuecomment-2816719627 に付け加えると

1. 全部諦める ← kkos氏の選択
2. モードスイッチでコンパイル時に切り替える
3. \U フラグ等で動作時に切り替える
4. 現行通り、[\s\S]!==. (つまり現行は中途半端な仕様になってる)
5. [\s\S]===. となるように仕様をアップグレードする

で、俺は5が良いと思ってる。これが正しい仕様だから。
しかしこれが速度的に無理なら、遅くなる正規表現にだけフラグ付けておき、
プログラマはアップグレードの度にそのフラグの除去を試し、最終的にこのフラグを全部除去する、の方が良いと思う。
ただ、現実的にシンタックスハイライター等での使用なら \U の方が手っ取り早いので、3も良い解だとは思う。
1.は良い解だとは思わない。

要は、速度の問題は内部最適化で隠蔽し、外面仕様に出すな、という事。
そしてトラックバックの制御を出来るようにする＝内部走査順が外面仕様に出る＝最適化ができなくなる、ので、
現行のトラックバック制御の仕様追加もいいとは全く思わない。
将来的にCPUがもっと爆速になって、放っておいても問題なくなったときに、糞ウザい正規表現のコードが残るだけ。
(とはいえ、現状、CPUが爆速になっていく見込みなんてないのも事実だが)

凡人エセプログラマーの私にはあなたが一体何をしているのかさっぱりわかりません
何やらすごいことをしているのは空気でわかります
しかし宇宙語並に理解不能なのでよければ軽く解説してくださるとうれぴいです

>>50
遅くなってすみません、やっと全部把握出来たので少しづつレスしていきます。

>>77
PHPのmbstringのmb_ereg()系の関数に使われている正規表現エンジンのOnigurumaが先月開発終了となりました。
その原因は /\w/i と /[\w]/i の動作が一致しない等の不整合があり、fixが手間的に難しいということでした。
Issue 349: https://github.com/kkos/oniguruma/issues/349

また、この問題とは別に大文字小文字を区別しない時の [\w] などが "ss" や "st" などの複数文字に一致すると
いう仕様 (これはUnicodeの仕様通りの動作) が原因で [\w]+ のように繰り返しなどを使った場合に
バックトラックが大量発生するケースがあり、本来ならマッチすべきケースでもエラーを出して検索が
止まってしまう場合がある、という問題があります。
Issue 351: https://github.com/kkos/oniguruma/issues/351

例えば検索される側のテキストデータに "sssssssss" などが入っていると [\w] に対して "s" 1文字が
マッチする場合と "ss" の2文字がマッチする場合の2種類を試すことになります。
この動作に繰り返し処理が加わることでバックトラックが発生した場合にものすごい試行回数になる場合があります。

50さん(超優秀な方)はこの２つの問題についての見解を書いて下さっています。

この件に関するPHPのてきとうなリンク
https://tekitoh-memdhoi.info/views/919
https://github.com/php/php-src/issues/18467

>> 個人的にはもしPHPが再び Oniguruma を取り込む場合は fix_351_349 ブランチ を取り込むことをおすすめします。
>PHPは互換重視、というより、互換絶対、だ。だから厳しいだろう。

了解です。私は頓珍漢なことを言っていたようです、すみません。

> 昨日mergeしたのか？

いえ、これは私がOnigurumaをforkしたリポジトリでのmargeです。
このmargeは不適切ということでforkしたリポジトリは削除しました、ご指摘ありがとうございました。
(セキュリティ上の理由でforkしたリポジトリは非表示に出来ないようです)

> fix_351_349ブランチ

現時点ではこの動作の切り替えは以下のマクロでしているようです。

#ifdef USE_DIFFERENT_CHAR_LENGTH_MATCH_BY_IGNORECASE
https://github.com/kkos/oniguruma/blob/5d0506c66c4d3613912fa81d7d1b99f83dbea8e2/src/regcomp.c#L4767

>> Therefore, choices for elements other than the character class are generated after the character class.
>ちなみにこの意味が分からない。

これは /(?i)[\S]/ を /(?-i)(?:s|t|st|ss)/ とみなす、だと思います。
"s|t" に続いて "st" と "ss" の選択肢が追加されるという意味だと思います。

> [r`(?i)^[^\W]$`, 'ss'], // ❌ ← むしろこれがアウトだろ、疑問マーク付いてないが

これはOnigurumaの最適化によって /(?i)^\w$/ として扱われていると思われます。

> // The negation rule is about negation of the outermost class, only 🤔 ←　この解釈が間違いで、
> [r`(?i)^[[^\W]]$`, 'ss'], // ✅ 🤯　←　これと
> [r`(?i)^[\w&&[^\W]]$`, 'ss'], // ✅ 🤯　←　これには俺は問題を感じない

これはおっしゃる通りだと思います、解釈の間違いですね。

> [r`(?i)^s{2}$`, 'ß'], // ❌　← これはヒットするべきでは？

確かにUnicodeの仕様上ではマッチが正しい気がしますね。ただ、こういうケースまで実装で対応するのは大変そうですね。

>「が(0x304c)」と「が(0x304b,0x3099)」... おそらくこの辺もonigurumaは対策されてるのではないかと思う。

テストしてみたところ、Oniguruma6.9.10 (UTF-8) では対応していないようです。
1. "\u304b\u3099" =~ /\x{304c}/ # マッチ失敗
2. "\u304c" =~ /\x{304b}\x{3099}/ # マッチ失敗

ROMってる方のために補足です。

> 1. 全部諦める ← kkos氏の選択
> 2. モードスイッチでコンパイル時に切り替える
> 3. \U フラグ等で動作時に切り替える
> 4. 現行通り、[\s\S]!==. (つまり現行は中途半端な仕様になってる)
> 5. [\s\S]===. となるように仕様をアップグレードする

これは大文字小文字を区別しない場合の話です。

次に、3. の "\U" について。
Issue 351の以下のコメントでは "\U" を "\w" や "\d" のような文字集合の一種として使っています。
github.com/kkos/oniguruma/issues/351#issuecomment-2816719627
このコメントでの "\U" は全ての1文字にマッチするだけでなく、"ss" や "st" などの特殊な複数文字にもマッチする、という仕様のメタ文字です。

5. の "[\s\S]===." は /[\s\S]/i と /./i が共に "ss" や "st" などの特殊な複数文字にもマッチする仕様にする、という意味です。
Oniguruma6.9.10 では /./i は "ss" や "st" にはマッチしませんが、/[\S]/i はこれらにマッチします。これについては以下のコメントをご覧ください。
github.com/kkos/oniguruma/issues/290#issuecomment-1807145668

Unicode: 特殊な複数文字の詳細
https://www.unicode.org/Public/UNIDATA/SpecialCasing.txt

補足おわり。

Onigurumaってそんなに関心もたれるものでもないんじゃ

>>78
すまん#349読んでなかった。
そして#264も読んだ。


まず全般的にだが、謝る必要は全くない。
君が不味いことをしたわけではない。
俺が偉いわけでもなく、正しいわけでもなく、決定権を持ってるわけでもない。
君は自由に、やりたいことを勝手にやればいいだけ。
俺は勝手にウダコダ言ってるだけ。正直、井戸端会議レベルだ。
GitHubは割とリアルなのである程度まともに振る舞うべきだが、5chでは死ね死ね言ってるくらいで丁度いい。

して#349、もう辞めます！ってか。なんか割と大事(おおごと)だが。
さすがに開発元が辞めてしまったら使用者側としてはどうにも動きづらいだろう。
一般的に、またPHP的に、ありがたいケースは順に、
・辞めるの止めます、で復帰してくれてそのまま開発継続
・主たるcontributorの誰かがforkして、大部分のcontributorがそこに集まって開発継続
・複数のforkでそれぞれ開発が行われ、その中で良さげなものを探して使う
・誰もforkしない、または使えそうなforkがないので、ひたすら現行バージョンを使う
　(バグがあってもそのまま、セキュリティ的に問題があれば落とされるかも？)
かな？
まあ今の採用バージョン知らんが、Version6.9.10を入れてからその先の話だから、だいぶ猶予はあるけども。

しかし唐突というか、なんだかねー。
大体文句しか言われないから、もう疲れたから止めます、あるいは本末転倒になって楽しめなくなったので止めます、は分かるけど、
実装できないので止めます、はねえだろオイ！と突っ込みたくなるよ。
実際のコードは見てないが、
if文によるハードコード(速いが分量が多い)だと多種エンコードに対応するのはほぼ無理ゲーなので、
関数ポインタを編み上げるタイプのソフトコード(という言い方はあまりされないが、最速ではないがあらゆる柔軟性が確保できる)であることはほぼ確実

なので、
いろいろ容赦なく突っ込まれて嫌になったか？とも思う。（どんな仕様でも実装自体は簡単のはず《ただし速度は遅くなるが》)
しかし、言っちゃ悪いが、 s と [s] の動作が違うのは実装が悪いとは思うし、突っ込まれてもそりゃお前のせいだわ、としか。
だからまあ、forkして勝手にしやがれ！俺はもう知らん！もありではあるが。

して、君はこれどうしたい？
普通に考えれば、最新リリースバージョンの Version6.9.10 まではPHPには入る。(いつになるかは不明だが)
だからPHPにVersion6.9.10が入れば満足なら放置でいい。
oniguruma単品で使ってて、あるいはVersion6.9.10でも不満があるのなら、
・まず仕様について積極的にcontributeしてるやつを探し、
・次にコードに対して同様にcontributeしまくってるやつを探し、
そいつらの動向を見て、みんなが集まりそうなforkに寄生して一緒に開発するのがまあ妥当。
何でもそうだが、開発には「仕様」と「コード」に詳しい奴が居ないと厳しい。
だから今の君だけで開発を牽引するのは無理ゲー。
ただし、一人でやる必要はない。
同様に宿り木を探してる連中はいるだろうし、
日本人のプロジェクトだったから日本人トップを望んでる日本人も多少は居るはずだから、
コードの良し悪しを判断できる奴を確保できれば、そいつと組んで、
君が「仕様」側のトップでツートップ/多頭体制で開発継続も可能ではあるだろう。
(すまんが俺はやる気ない。PCREで間に合ってるし、oniguruma使う予定もなく、あってもv6.9.10で十分だし)
まあ5chの正規表現スレ(どこだったかは忘れたが)にたむろしてた連中も大騒ぎしてるだろうし、
そいつらからもリクルートできるのではないかと。
(連中が仕様に詳しいのは確かだが、コードは書けない感じだし、
そもそも人格や報連相に問題があるかもだが、これら含めてOSSだしそんなもん。
開発者がいきなり交通事故で死ぬこともあるのだから、細かい文句を言ってても始まらん)

> 了解です。私は頓珍漢なことを言っていたようです、すみません。 (>>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だからコンパイル時に切り替えだね。
ただコード見る限り、俺が想定してたのとはだいぶ違う。(いいか悪いかは別、というかそこまで読んでない)

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

>>82
正規表現ライブラリの問題は、多分「仕様」側と「実装」側が乖離してる事。(これは他の非プログラマ向けソフトも同様だが)
正規表現の使用対象をざっくり二分すると
・ソースコード
・自然言語
で、「実装」側、つまりプログラマは前者なのでasciiが通ればほぼ問題ない。
PHPではユーザー入力やDB登録されてるテキストが後者になるので、多少は取り扱うけども、
基本はGUIのサポートなので、ハズレたらハズレたで問題ない程度でしかない。
それよりは、自動(正規表現はソースコード内)で使うので爆速な事が必要。
「仕様」側、例えば文献検索で小説本文から対象文字列を抜く、回数を数える、みたいな使い方だと、抜けがあったらそれなりに困る。
ßはssにヒットしないと、使い物にならない。
ただこちらは基本的に手動(正規表現は手打ち)なので、人間が我慢出来る速度なら問題ない。

だから、求められる正規表現ライブラリの仕様は、
プログラマ向け：ascii専用でいいから爆速
非プログラマ向け：unicode規約に則った、自然言語対応型。速度は遅くても構わない
で、おそらくonigurumaも基本は前者で、
ついでに後者向けにunicode規約満たしてみたら(多分だが他が全く対応してないので)
自然言語を取り扱う連中には重宝され、あちこちに採用されたはいいが、「これはバグですか？」的な報告が大量に来る事となり、
kkos氏自身はasciiだけで満足出来る側だったので「もう知らん」になったとか、かと(全部推測ですが)

だからプログラマはPCREで満足してて、mb_xxxのonigurumaにはあまり関心がない。
使ってなく、使う予定もないから。

>>78
ご説明ありがとうです。
ChatGPTに聞きながら読んでみたけど、結論正規表現的には日本語はクソって言ってました。
とにかく恐ろしいほどの苦労があることはわかりました。

>して、君はこれどうしたい？

正規表現についてはもう十分な知識を得られたと思うので次は教えて頂いた通りに
C言語を本格的に始めてみようと思います。以降スレ違いになるのでこちらでお願いします。

c言語教えてくれ
http://2chb.net/r/tech/1728823763/

PHPスレのみなさまありがとうございました。お邪魔しました。