観察日記 2010-07-15 - なるせにっき

C言語数値リテラルの接尾語の話

[ruby-dev:41782] この件
{util_mput} [ruby-dev:41782] [Bug #3522] String::size return invalid size on mswin64 http://tinyurl.com/25zkthh
http://www.atdot.net/sp/view/q5915l
{util_mput} q5915l - SimplePaste view http://tinyurl.com/2u3njon
こういうことじゃないだろうか
ULL って書ける？
あぁ、なるほど
って、mswin64ではそこ行かないはずだけど
そうなの？
count_utf8_lead_bytes_with_word の中で NONASCII_MASK >> 7 ってしてて
mswin64はLLP64だから、SIZEOF_VALUE == 4
VALUE はポインタのサイズだから SIZEOF_VALUE == 8 じゃない？
VALUEはvoid *のサイズでFixnumがlongか
そうだな、混乱してた、その修正で正しいと思います
うむ
こみっとしてください
自分で試せてないので怖すぎるのですが
64bitプラットフォームでとりあえず試せばいいんじゃ
なんと 64 bit プラットフォームももっていないのだ！
なんと
いや再起動すればいいんだけど
今時珍しい
めんどい
linuxもないの?
普段使ってるのは 32bit な linux と windows で
windows のデュアルブートとして 64bit な Debian も起動できるけどめんどい
じゃあうちで試す
おおおおねがいします
FreeBSD amd64だけど（ぉぃ
再現する環境ならなんでも
再現しないけどregressionしてないことはわかるとかいう
再現しないのか
あの長さだと再現しないのかな
アラインに依存して発症したりしなかったりすると思われる
p ("~"*100 + "\u3042").size で
100 を適当に変えれば変なことになるんじゃないかな
100-110まで試したけど発症しないな
なんででしょうね
発症しない理由がわからない
まぁ、気を利かせてULLにしてるんじゃない
いやあ、それはコンパイラのバグだと思うが
うーん、再起動するか

確かに再現しなかった
0x8080808080808080LL というリテラルに相当する数値は存在しないので
そういうときは勝手に unsigned にしていいとか
そういう仕様なのかな
おー
C99 のドラフトを見てみたが
0x...LL と書いた場合は、long long int で表現できるならそれ、できないなら unsigned long long int で表現できるならそれ、できないならなんかさらにややこしいルール
らしいので、VC のバグと言えそうだ

今頃ULLの話とか見たけど
VCはC99準拠じゃないからC99の仕様なんか知らんがな
だと思う。
つまりC99の仕様に依存したコードを書いてる奴がバグ
C89でも0xはunsignedじゃなかったっけ
さて
規格書は大阪に
http://www.jpcert.or.jp/sc-rules/c-pre12-c.html
{util_mput} PRE12-C. 数値定数は移植性のある方法で定義する http://tinyurl.com/285qa63
うーむ
{unak} 接尾辞のついていない16進定数は、32ビットで表現可能でありかつ上位ビットが立っている場合、unsigned int として定義される。たとえば、0xFFFFFFFFL は 32ビットシステムでは signed long である (すべてのビットが '1')。
素で意味がわからない。
接尾辞がついていれば接尾辞が優先される、と言いたいのかなあ。
ryのCリファレンスマニュアルを見ると、
ずのみかたがむつかしい
0xddddはint->unsigned->long->unsigned long
0xddddLはlong->unsigned longとよむのかな
0xfffffffL が signed なの？
足りなくないかそれ
こまけえこたあ
接尾語は、その型の最小の大きさをしめすらしい
もうちょっとくわしく!
long といったらそれより小さい int とかにはならない
そゆこと
ふむ。
でと。
で、Lつけなくてもintで収まらなかったらもっとおっきいの使う
いやLはlongだから最初からlong以上だ
0x系はint->unsigned->long->unsigned long->long long->unsigned long longの順で使う
LとかLLは開始位置を決める
で。
最上位ビットが立っているというのはどうなんですか奥さん
unsignedだよなあ。
最上位ビットが立っているとlongで収まらないからunsigned longを使う
無理やり突っ込んで負の値にしたらダメよってことでしょうな
というわけで、規格の解釈はそういうことで納得したのだが
JPCERTさんとVCは何を言っておるのかね、ということになるね。
何を言っているんだろう
JPCERTさんのは文の繋がりが言葉足らず過ぎておかしい気がするので、ミスですかねえ。
で、VCは「LLは独自なのでどう扱おうが俺の勝手だ(キリッ」と。
原文を見よう
https://www.securecoding.cert.org/confluence/display/seccode/VOID+PRE12-C.+Define+n
umeric+constants+in+a+portable+way これかな
それっぽいな
原文どおりだー
VOIDってなに
Eliminated Sections
まぁ、ですよね
アホ過ぎて削除された?
そもそもPREはプリプロセッサを意味するようだが、もちろんプリプロセッサの話題じゃないしな。
https://www.securecoding.cert.org/confluence/display/seccode/99.+The+Void
なにがなにやらだぜ
というわけで、CERTもたまには馬鹿である、と。
Microsoftはまあいつものように馬鹿である、と。
こういうことにしておきましょうか。
また勉強になりました。ありがとう。
また重要な知見が得られた

コミットのレビュー

ただ日頃の運営みていてちょっと気になるのは、コミットパッチをレビューしてバグ報告してくれてるのってakrさんだけな気がする
田中さんもあまりそこにモチベーションがでないとこの間言ってた
これはakrさんの負荷が大きい気がするので
コミット読むのは大変だからねえ。読まないで済むような仕組みが必要だな。
コミットに目を通すとかすげえな
コミット直後によむか直前に読むかという違いがあっても、負荷は変わらないきがする・・
いや、それこそ分担可能で
レビュア制度でも入れますか
経験則てきに一番メジャーなマイナープラットフォームの考慮漏れは１−２人レビューすると、まあ指摘可能なので
開発はほぼ停滞する
たしかに・・・
acked-by何人未満は入れちゃダメとか
1人でもackしたらOK。でも相当大変だけどね
YARV の中身とかレビューできる人ってどのくらいいるかな
mameさん
まあ実は俺も1.8限定だけどコミットは読んでいる(読まないと判別できない)が、バグが増えているかという観点では読んでないから残念だ。
#2611 とか、ack を出す自信がなかった
まあ理想を言えばackよりテスト書けといいたい。コミットには必ずテストをつけろ
でも必ずといっちゃうと面倒な場合が出てくるんだよねえ。
net系とか結構頭痛がする
あとgem
ああ、そうしましょう
必ずテストを書けとか、テスト書いたことのない人のセリフですよね
テストとレビューのor条件にしたら、だいぶ現実的
まぁ、新機能には義務づけていい気はする
ちなみに僕のテストはずさんだよ（キリリ
必ずではないがバグフィックスにテストを書いてくれているなかださんは神。
コミットなんて読んでないよ
うそー
あれだけ、コミットミスを指摘しまくっておいて
エスパー能力とでも言う気ですか・・・
ビルドログの変化は見ている
基本的には chkbuild がどうかなったら報告してるんだと思ってた
でも変化したらコミットも読むでしょ
読まないことが多い
自分に関係しそうなら読むかも
concov 作ったものの、変化を継続的に見るという人間力が足りなかった
いやまったくそこが問題で。
CI ツールに一番必要なのはそれを見る根気ですね
ささださんメールのCIって何の略？
continuous integration
ほぼ常にグリーンに保つ習慣があればそんなに大変じゃないと思うんだけどなぁ
今はわりとましな状況じゃないですかね
この状況を保ちたい
保つためならrevertも辞さない
rubyspec が fiber の ensure でエラーはくのが嫌
うむ
それならとりあえず fiddle を revert しろって
fiddle がなんか動いてないんですか？
何かあったっけ？
fiddle が入ってからずっと test-all が core 吐いてるな
fiberとfiddleの因果関係がわからない
187は常に0F0Eだぜと思ってたらwebrickでEが増えてた上に気づいてなかったという大失態
boron では
なんでだろう
最近 znz さんがチケットにしたような
test_activation(TestGemActivation) も放置しないでほしい
しかし、CI の観察を楽にするには今の状態では足りない
エラーが出た状態で放置した時間だけ人徳が減っていると知るべし
少なくとも boron ではずっと失敗が残っているし
人徳でプロジェクトが回るならこんなに苦労せんのですよ...
59 tests, 407 assertions, 0 failures, 0 errors, 0 skips あれ？
寿命にしようか
boronってなんか特殊な環境なのかな
あぁ、それぞれ分離したのか
rubyspecでffiとかcapiのノイズが
chkbuild は test-all 全体が異常終了すると分割してテストするので
実際のところこの機能もレポートするモチベーションを低くする影響がある
あ、すいません。文脈が読めませんでした。分割テストとモチベーション低下の関係はどこに？
ログが見にくくなるということかしら
test-all が SEGV して結果が出力されない状況はさすがにフラストレーションが溜るのでレポートする気分になる
そんな。。
が、分割して実行してくれれば、結果は観察可能なので、あまり困らない
SEGV するところは観察できないが、そこはだいたい自業自得だし
分割したら SEGV しなくなる、ということはそれほど発生しないですか
それはある。今もそう
そうか、fiddle と gdbm とか言ってたあれか

Linux と Thread

あ、n0kadaさん、ちょうどいいところに（がしっ）
なにごと
Bug#2553の歴史的経緯が理解不能です
1.8だけruby_setjmpがgetcontext()呼んでるのはなぜですか？
signal handlerから戻るときに問題になるから、じゃなかったかな
1.8と1.9でシグナルハンドラは作りが違う物？ --enable-pthreadでも
えーとMLのrefがあったっけ
ある
あるけど、僕には意味不明すぎた
getcontextの7割はsparcのregister windowのためにあるって前誰かがいってた
人間の体の6割は水から出来ている、みたいなもんですか。
それは・・・どうだろう。register stackあると、どのみちああいうナイーブな保存・復帰インターフェースはあんまり効率的じゃ・・・
例：くそia64
つうか本来ならsetjmpなんだからregister windowの面倒はsetjmpでちゃんと面倒みろよ!と思うのだけど、世の中はそうも単純ではないらしい。
まあsparcはregister windowに関してはパイオニアなので
パイオニアであるがゆえの考えが足りてなかったところとがあるのはしょうがないとして
ia64は全く弁護できないな...
同意
あれはOS世界の汚さを知らないコンパイラ屋さんの夢がつまったCPUだ
[ruby-core:01932]か
segvしてたのが直ったということでコミットしたようだ [ruby-core:01944]
[ruby-core:01935]で、rb_thread_restore_contextでは落ちなくなったといわれて
まだ落ちるというlongjump_destination()にも同じようなことをしてみたのかな
ああ、わかったかも
この当時はLinuxのスレッド実装がLinuxThreadなので
シグナルがメインスレッドに飛んできます（全スレッドが別pidを持つ事による副作用）。なので、メインスレッドはシグナルマスクをやたら注意深く変更しないと即死
この仮定がただしければ
現代はLinuxThreadはすでに死滅したので・・
したの?
したことにしてもいいような。
2.6カーネルとだいたい同時期にNPTLにスイッチ。これがだいたい７年前
個人が根性で使い続けているひとはいるかもしれないが
メンテ続いているディストリはないと思う
LinuxThreadは滅びんよ、何度でも蘇るさ
やーめーてー
思い出したくないfeature > LinuxThread
vine4とかLinuxThreadsじゃなかったっけ?
えっ
LinuxThreadとNPTLって実行時に区別する方法がなかったような気がする
libcを実行すればわかるのか
実行時に知る必要ないよ
ビルド時に指定できれば
{kosaki} -bash-4.0$ /lib64/libc.so.6
{kosaki} GNU C Library stable release version 2.11.2, by Roland McGrath et al.
{kosaki} Copyright (C) 2009 Free Software Foundation, Inc.
{kosaki} This is free software; see the source for copying conditions.
{kosaki} There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
{kosaki} PARTICULAR PURPOSE.
{kosaki} Compiled by GNU CC version 4.4.3 20100127 (Red Hat 4.4.3-4).
{kosaki} Compiled on a Linux 2.6.32 system on 2010-05-20.
{kosaki} Available extensions:
{kosaki} The C stubs add-on version 2.1.2.
{kosaki} crypt add-on version 2.1 by Michael Glad and others
{kosaki} GNU Libidn by Simon Josefsson
{kosaki} Native POSIX Threads Library by Ulrich Drepper et al
{kosaki} BIND-8.2.3-T5B
{kosaki} RT using linux kernel aio
{kosaki} For bug reporting instructions, please see:
{kosaki} http://www.gnu.org/software/libc/bugs.html.
と、libcを実行ファイルとして実行すると
NPTLだとNative POSIX Thread ってでる
configure時なら、このぐらい無茶な非効率でも・・・
もしかしてvine4って終わってる? > http://vinelinux.org/roadmap.html
おお、本当だ本当だ２０１０年でちょうど終わったwww
http://www.atdot.net/sp/readonly/i0ad4l Vine4.2のはず
結論としては、LinuxThreadsかsparcのときだけucontextということ?
http://www.atdot.net/sp/raw/bxad4l
/lib/libc.so.6 って必ずあるもの?
x86_64だと/lib64 だったりするので、適当なバイナリをlddしてパスを引っこ抜いた方がいいかもしれない
x86_64でもLinuxThreadsってあったの?
ああ、そうか、ないな > x86_64 でlinux thread
NPTLでコンパイルしたバイナリをLinuxThreadsに持っていったりはしないだろうな
心配しすぎといったのは、NPTLでコンパイルしてLinuxThreadsにもっていくほう。これは他にも色々と動かなくなる原因があるので、考えるだけ無駄
{n0kada} if test `(/lib/libc.so.6 2>/dev/null | fgrep 'Native POSIX Threads') 2> /dev/null`; then
{n0kada} use_context=yes
{n0kada} fi
このくらいかな
ああ、なる
target_osが問題なのにhost_osのlibc.so.6でチェックしても意味ないな
そう考えるとlibcを実行するってのはクロスコンパイルで不可だな
クロスコンパイルしてる人は実在します？
linux用はしてないな
mingw用はいつもクロスだけど
ARM用とかの組み込み向けだといるかもしれない
それは必然的にクロスだな
クロスのときは自分で指定しろ、でどうだろ
クロスはハードル高くてもしょうがないと思う
http://www.atdot.net/sp/raw/nsbd4l
$cross_compiling = noのときだけlibcをチェックするように
はやいっ
クロスはそもそも他にもいろいろ手動で指定しないとダメなことが多い。

Rails 3 と Ruby 1.9 と地雷原

railsは結局うごいたんでしたっけ
いちおう動くということになっていると思った。知らんけど。
g:>rails3
{ko1_ndk} google web bot:: Ruby on Rails Guides: Ruby on Rails 3.0 Release Notes - http://guides.rails.info/3_0_release_notes.html (and 65,100 hits)
{znz} >Rails 3.0 is also compatible with Ruby 1.9.2.
1.9.1はダメだから1.9.xなら1.9.2を使えと言うことらしい。
{znz} >Note that Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails 3.0. Ruby Enterprise Edition have these fixed since release 1.8.7-2010.02 though. On the 1.9 front, Ruby 1.9.1is not usable because it outright segfaults on Rails 3.0, so if you want to use Rails 3 with 1.9.x jump on 1.9.2 for smooth sailing.
結局1.9.1は使ったことない・・・
しかし、Rails様のようなお得意さんについて「知らんけど」とか言っちゃうのはひどいな。
Rails3とRuby1.9と両面作戦で地雷踏みに行くやつは
やっぱマゾだよ
先駆者
つか、coreっぽい人でRails様を見てる人はいないの?
coreっぽい人で言うとJEG2とか?
俺はもう担当が既に地雷原なのでこれ以上別の地雷原に踏み込む余力がない。
あるいはyuguiさん
うん。
使ってはいるけどまだ地雷っすね。
それはどっちのせい?
松田さんをcoreに取り込むかねえ