mklocale(1)も修正した
最新版、
localeioの__convertgrouping()が
strtol(3)に依存してマジで血管切れる5秒前だったが
FreeBSDからfix_grouping.cをパチってきて回避
...できたたかなー思ったらisdigit(3)呼んでて泣いた、おっおっ。
ちゅうかなぜ彼らはsetlocale(3)の内部処理で、localeに依存する関数を
呼んじゃ駄目とい事に気付かんかな、プログラミングの基礎だろJK。
まぁ本当はsnprintf(3)なんかも駄目なんだが、そこまで徹底するには
完全にmulti-localeの実装が終わらないと無理ぽ。
じゃぁなぜここの部分のstrtol(3)やisdigit(3)だけは放置したらまずいかというと
mklocale(1)はcross-toolchainなので、strtol(3)やisdigit(3)は
hostのlibcのものが使われてしまうちゅーのが理由。
joerg氏が先日strtolファミリーをtemplate header化してくれてたお陰で
助かった、tools/mklocale/safe_strtoul.cね。
あとNetBSD toolchainってよく知らんのだけど、fix_grouping.cはCHAR_MAX使うんだが
これhost環境のCHAR_MAXになっちまう気がする、これなんかnbcompat.h的な
ものの中でtarget環境のCHAR_MAXを使うようになっってるんだっけ?
常識的に考えるとそんなん無理、な気がするんだけど。
そいや以前FreeBSDで_RuneLocaleがpublicな為toolchainのbuildがこけるんで
_NBRuneLocaleにrenameかけたりしてた記憶がある、やっぱり駄目か。
つーわけでそこもTODO追加。
まぁでももうcoreに投げても良い頃合いだろかね。
なんかここがダセェー、ゲロの臭いが(以下略)な部分があったらご指摘ください。
もうすでに_RuneLocale(runetype.h)及び_{Monetary,Numeric,Time,Messages}Locale
(localedef.h)を分離する時間が無かったので、個人的には好かんコードなんだけど。
がーそういやCHAR_MAXはMDだった、ということはlibcはdbを読んだ後に
3;3;-1 -> \003\003\117\0に変換かけねばならなんのか、うわー無駄だ。