SAKURA Development BBS(UNICODE)

▼ 2014/12/31 (水) 13:08:40 匿名

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2223] ダブルクォーテーション文字列の判定が変

Onigmo-5.15.0 のソース regexec.c の 1396 行目からダブルクォーテーション文字列の判定が変になります。
https://github.com/k-takata/Onigmo/blob/Onigmo-5.15.0/regexec.c#L1396

2.1.1.4 Stable と Rev.3908 で確認しました。

▼ 2014/12/31 (水) 16:28:40 もか

INCM1.23a

[2224] Re: ダブルクォーテーション文字列の判定が変

そのURLで確認しました。
今の実装だと、「R"なにがし(」の文字列は、C++11のRaw Stringとみなされるので、
その終端がないものとして、この場合は「) "」が現れるまで文字列になります。
もしRと"の間にスペース1つでもあればRaw Stringとは認識されません。
これどうしたらいいと思う？

1. Rの直前にu8w以外が来ているかチェックする
\b(u|u8|w)R"[^(]*\(
の正規表現相当でチェック。\bの具体的パターンはよく分からない。

2. C++とは別にC/C++03文字列を追加してそっちを使ってもらう
作るのは簡単そうだけど、使う人が面倒
しかし、""文字列型を汎用として使うにはR"str...も普通の文字列としたい場合などあったほうがいいかも。

1.2.両方かな。
PRIdPTR等はC99みたいなので、何とかしようと思います。

▼ 2014/12/31 (水) 16:39:53 もか

INCM1.23a

[2225] Re2: ダブルクォーテーション文字列の判定が変

>\b(u|u8|w)R"[^(]*\(
訂正。たぶんこう
\b(u8|u|U|L|)R"[^(]*\(

\bはたぶん
^|[!"#$%&'()=@{};:<>?,.*/\-\+\[\]\\s]

▼ 2014/12/31 (水) 19:35:45 もか

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2226] Re3: ダブルクォーテーション文字列の判定が変

パッチをトラッカーに登録しました

https://sourceforge.net/p/sakura-editor/patchunicode/954/

▼ 2014/12/31 (水) 21:41:19 匿名

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2227] Re4: ダブルクォーテーション文字列の判定が変

お疲れ様です。

▼ 2015/1/4 (日) 14:34:44 suzz

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2228] Re4: ダブルクォーテーション文字列の判定が変

>C++ Raw StringがR"で終わる識別子でRそのものでない(PTIdPTR等)場合にも

・・・わけがわからないよ。
もう少しわかるように書けない？
また、どう直したのかを自然言語でも書けないかな？

また、「#956 カラーの文字列にC言語風を追加」ですが、
C言語風 / C++言語風 よりは、C/C++03 / C++11 という定義名にして、
デフォルトは C/C++03 にしませんか？

▼ 2015/1/4 (日) 22:15:51 もか

INCM1.23a

[2229] Re5: ダブルクォーテーション文字列の判定が変

>>C++ Raw StringがR"で終わる識別子でRそのものでない(PTIdPTR等)場合にも
>・・・わけがわからないよ。
(キューベーのAA略)
「Rで終わる」ってのはxxxxR"hoge(str... って意味で
「Rそのもの」ってのはR"hoge(str.. て意味で書いたけどこれは不正確だった。
でその2つが「かつ」って書いてないけどかつの場合。
if( 'R' == str[nPos-1] ){ // Rで終わる識別子
    // 旧:Raw String定義
    if( IsRawStringPrefix(str, nPos) ){
       // UR,uR,u8R,LR,R の識別子(直前が記号類・空白か行頭)
       // 新:Raw String定義
    }else{
      // 上記の「場合」とはここの意味。ここは条件から外す。
    }
}
>また、「#956 カラーの文字列にC言語風を追加」ですが、
>C言語風 / C++言語風よりは、C/C++03 / C++11 という定義名にして、
定義名は変更しようと思います。
>デフォルトは C/C++03 にしませんか？
C++11のほうを追加にして、
C/C++03(旧C/C++言語風)ではRawを色分けしないように仕様変更。
CType_CppのデフォルトだけC++11にしました。
旧設定から引き継いだC/C++タイプ別はC/C++03になります。ので、Rawを色分けしたい人は手動で設定を変更する必要があります。
2011年から4年も経過しているわけで、私個人としてはC++は04準拠で行きたいと思います。
サクラエディタのソースは違うけど。
新規格を取り込んでいかないと緩やかに死んでいくだけ。
Cの定義がっていう場合はそろそろタイプ別を分けたほうがいいと思う。
もはやCの上位版がC++とは言えないし。

▼ 2015/1/5 (月) 22:44:44 suzz

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2230] Re6: ダブルクォーテーション文字列の判定が変

正規表現とか擬似コードに頼らずに日本語で書いて欲しいな。

コードを読まないと何やってんのかわからないのでは、
読む側は時間がかかるばっかりで嫌になっちゃうよ。
（サクラエディタのコードはうんこなんだから、できるだけヒントは欲しい。今北産業で。）

>旧設定から引き継いだC/C++タイプ別はC/C++03になります。ので、Rawを色分けしたい人は手動で設定を変更する必要があります。
>2011年から4年も経過しているわけで、私個人としてはC++は04準拠で行きたいと思います。

落とし所としてはこの辺ですかね。
新機能を入れるのはいいけど、利用者のことも考えてほしいなと。
(まあ、私はサクラエディタを使っていない人の筆頭なのだが)

> Cの定義がっていう場合はそろそろタイプ別を分けたほうがいいと思う。
> もはやCの上位版がC++とは言えないし。

ヘッダファイルがどっちも .h のことが多いので、分けるとそのへんが辛いのでは。

▼ 2015/1/6 (火) 02:17:19 もか

INCM1.23a

[2231] Re7: ダブルクォーテーション文字列の判定が変

>コードを読まないと何やってんのかわからないのでは、
>読む側は時間がかかるばっかりで嫌になっちゃうよ。
どちらかというと変な日本語読んで混乱しているより、
さくっとコード差分みるのが早いとおもうんだけど、違うかな。
特にこのパッチは簡単な部類の処理なのでC++アレルギーとかCOBOLしかわからんとかでなければ。
最近はかなりの量をコミットしてるので、全部見るのは相当しんどいと思うけど。

>正規表現とか擬似コードに頼らずに日本語で書いて欲しいな。
それBNFで定義してるHTML5とかRFCとかディスってるの？
俺に日本語期待しても無駄だぞ。

>\b(u8|u|U|L|)R"[^(]*\(
>^|[!"#$%&'()=@{};:<>?,.*/\-\+\[\]\\s]
挑戦してみた。
!"#$%&'()=@{};:<>?,.*/-+[] 半角スペースおよびタブ文字のいずれかの文字
または行頭だった場合かつ、
それに「u8R"」「uR"」「ULR"」「LR"」「R"」のいずれかの文字列が続きかつ、
その後ろに0文字以上「(」以外の任意の文字列が続きかつ、
さらにその後ろで改行までに「(」が現れた場合に、
Raw String とみなします。
いままでは、
「R"」の後で0文字以上の任意の文字列の後に、「(」が現れた場合に、
Raw String とみなしていました。

>（サクラエディタのコードはうんこなんだから、できるだけヒントは欲しい。今北産業で。）
(否定はしないが)汚い言葉を書く以上は、ぜひSuzzさんのウルトラスーパーすばらしいコードをですね、
と思いちょっと#if 0のコードを読ませてもらいました。よければポートしたいですし。
「#if 0」「#if 1」でタブだった場合とか2文字以上スペースがある場合は考慮されてない。
#とif, else, endifの間にスペースがある場合は考慮しなくていいのかな。
wmemicmpになってるけど、「#IF 0」とかも認識しちゃうけどいいのかな(プリプロセッサの仕様は詳しく知らない)。
あとはもし、完璧を目指すなら、文字列中のコメントらしい文字は文字列になるはずなので、その考慮が必要かも。
一か所 $endifになってる。
CColor_Comment_Cpp_If1::Match_CommentTo とかのwmemicmpがバッファオーバーランしてるところがある
ちゃんと見てないけど、colorStrategyStateの取り回しは良さそう。
実行は試していない15分斜め読みクオリティーなので、間違ってる所あるかも。
ちなみに「#if 0」をコメント開始「#e」をコメント終了にしてしのいでます。

▼ 2015/1/6 (火) 14:17:23 もか

INCM1.23a

[2232] Re8: ダブルクォーテーション文字列の判定が変

自己突込み
>バッファオーバーラン
×
○：範囲外アクセス
読み込みだけでは、バッファオーバーランとは言わないと思う。全然違うがな。

▼ 2015/1/6 (火) 22:56:15 suzz

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2233] Re9: ダブルクォーテーション文字列の判定が変

例えば、

C++11 Raw String の開始判定において、単語区切りを認識して
判定を行うように変更した。
(単語の区切りは、記号、ホワイトスペース、もしくは、
行頭の場合)

とか。100% 正確でなくても、コードや正規表現を読む
よりも、すばやく変更の概要が伝わるように。

コミットログやBTS/ITSのチケットなどを、他の人に
わかりやすく伝えたいと思って書かない人は、
コードも他の人が読みやすいようには書かないでしょう。
なので、諦めずに行きましょう。

私もご指摘の通り、うんこコードを書いていますので、
説得力はありませんが、サクラエディタのコードがこれ以上
うんこコードにならないように、善処いただけると、
ファンとしては嬉しいです。

>「#if 0」「#if 1」でタブだった場合とか2文字以上スペースがある場合は考慮されてない。
>#とif, else, endifの間にスペースがある場合は考慮しなくていいのかな。

私が仕事でメンテせざるを得なかった #if 0 だらけの
うんこコードは、サクラエディタを使って書かれたコード
だったらしく、概ね "#if 0" で統一されていました。
なので、上記のケースは考慮しなくても大丈夫でした。

私のうんこコードは出来も悪いので、取り込まないで
頂きたいのですが #if 0 / #if 1 ネスト対応は本家サクラエディタで
対応されるとありがたいユーザはそれなりにいると思います。
（C言語しか書けない（ような情けない人たちがIT土方を
やっている）組み込み業界では）

>実行は試していない15分斜め読みクオリティーなので、間違ってる所あるかも。
コードレビュー、ありがとうございます。

▼ 2015/1/10 (土) 22:56:58 suzz

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2234] 紅桜の #if 0/#if 1 コード不具合について

> ○：範囲外アクセス
> 読み込みだけでは、バッファオーバーランとは言わないと思う。全然違うがな。

よろしければ、どのあたりが範囲外アクセスを行っているか、教えていただけないでしょうか？

ちなみに、

$endif はくだらないミスですね。。。
文字数が合っているので、かろうじて不具合にはなっていないようですが。

プリプロセッサに大文字は無いようなので、wmemicmp を使用しているのは不具合です。
おそらく、CBlockComment.cpp を流用したので、あまり考えず wmemicmp を使ってしまったのだと思います。

▼ 2015/1/11 (日) 03:19:49 もか

INCM1.23a

[2235] RE: 紅桜の #if 0/#if 1 コード不具合について

>> ○：範囲外アクセス
>> 読み込みだけでは、バッファオーバーランとは言わないと思う。全然違うがな。
>
>よろしければ、どのあたりが範囲外アクセスを行っているか、教えていただけないでしょうか？
これ、CStringRefは元がCNativeWだった場合は、NUL文字が末尾についていることを保証できるので、
呼び出し元を含めたコード全部を考慮にいれた場合は、大丈夫みたいです。
すみません。

細かく対応しようとすると面倒がおおいですね。
行をまたいだでプリプロセッサがコメントアウトされた場合
/*
#endif
*/
とか。
厳密にはOKなのか知らないのですが、ifの直後に括弧がある場合とか、
#if 0
#if(1)
#endif
#endif

memcmp/wmemcmpって、
比較が一致しなかった次の文字にはアクセスしたらいけないのですよね？
先頭から1文字づつ比較しないといけなくて、
intとか8バイト以上とかで一致するか見るだけの場合にループで書いたのほうが速いとかありそう。
まぁ今のマシンは100MBをコピーしても一瞬だったりするから気にしたことないけど。

▼ 2015/1/11 (日) 04:04:18 もか

INCM1.23a

[2236] RE2: 紅桜の #if 0/#if 1 コード不具合について

>比較が一致しなかった次の文字にはアクセスしたらいけないのですよね？
気になったんで(英語はよく分からんから)JIS X 3010:2003をwebで閲覧してみたけど、(w)memcmpの箇所に
有効バッファ長(n)のうち一致しなかった文字の後ろにアクセスしちゃいけない
とは書いてないので、
memcmp( "ab", "abcdefgh", 8 );
こういうのは、厳密な定義によるなら範囲外アクセスになるかどうかは実装依存かも。
サクラのほかのコードでも引数のs1,s2両方の長さが、n未満の場合がある使い方をしてるっぽいので微妙だ。

▼ 2015/1/12 (月) 16:55:15 suzz

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:34.0) Gecko/20100101 Firefox/34.0

[2237] Re2: 紅桜の #if 0/#if 1 コード不具合について

> >よろしければ、どのあたりが範囲外アクセスを行っているか、教えていただけないでしょうか？
> これ、CStringRefは元がCNativeWだった場合は、NUL文字が末尾についていることを保証できるので、
> 呼び出し元を含めたコード全部を考慮にいれた場合は、大丈夫みたいです。

ありがとうございます。
文字の比較に memcmp(wmemcmp) を使うのも微妙な感じがするので、wcsncmp で比較する形にしようと思います。
(条件判定１回分省略したい・・・とも思わないので。)

> 細かく対応しようとすると面倒がおおいですね。
私は「いい加減」なので、あまり細かく対応せずとも、現状のブロックコメントより改善されれば良いかなと思っています。

#if 0/ #if 1 は、往々にしてコメントアウト目的のコードですので、
色分け表示する以前に消せばいいのですが、それを許してくれない現場も残っています。

[▼次のスレッド]

INCM/CMT
Cyclamen v3.81

[ut:0.020][st:0.010]