25/11/18 16:36:11.76 d9hs+rsN0.net
cのcgiだって可能だしあってもいいだろ（？）
170:デフォルトの名無しさん
25/11/18 23:45:44.92 +AochNn2a.net
windows で
setlocale(LC_ALL, "ja-JP.UTF8"); とか
setlocale(LC_CTYPE, "ja-JP.UTF8"); とか
プログラムの先頭で設定しても無駄？
console は chcp 65001 してる
fopen() のファイル名に UTF8 で渡したいんだが
出来れば readdir() も UTF8 で取得したいのよ
171:デフォルトの名無しさん
25/11/19 07:24:28.12 1qR7LTyn0.net
ソースコードがSJISなら無駄
172:デフォルトの名無しさん
25/11/19 10:44:13.50 sa05/K8dd.net
opendir and readdir themselves work on bytes. They do not perform and reencoding.
Some filesystem drivers may impose contraints on the byte sequences.
I would expect the form returned by readdir to work when passed to opendir.
I'd like to know how you were able to find out that opendir and readdir do not perform any reencoding?
You can trace it through the C library source and the kernel code.
If you run strace ls, you can directly start from the kernel entry point: the open syscall.
The generic filesystem support code passes all bytes other than null and / along unmodified.
It's only some filesystem drivers that transforms file names.
173:はちみつ餃子
25/11/19 11:29:22.16 MnCaLNwG0.net
>>170
普通の入出力はテキストモードとバイナリモードがあって、ロケールの設定がテキストモードの振る舞いに影響するんだけど……
Windows の場合はテキストモード・バイナリモード・ユニコードモードに分かれていて _setmode でユニコードモードに設定する必要がある。
しかしユニコードモードの設定はワイド入出力系関数 (wprintf など) にしか影響を及ぼさない。
そんでその辺の設定をしても、入出力の内容に関してであってファイル名を UTF-8 で渡すのはたぶん駄目なはず。 (確認はしてない。 すまぬ。)
ファイル名はワイド文字 (UTF-16) に変換してから _wfopen で開くのが正当な方法だと思う。
Windows に readdir は無いので FindFirstFileW, FindNextFileW を使うのが普通の方法。
だいぶん前に調べたときは msvcrt と ucrt でちょっと振る舞いが違ったような記憶があるのでそこらにも注意が必要。
ucrt は色々と大きく改良されているみたいなのでひょっとするともっとモダンな方法があるかもしれない。
174:デフォルトの名無しさん
25/11/19 12:12:33.50 DtAPl5720.net
UTF16は廃止してほしい
175:デフォルトの名無しさん
25/11/19 13:55:46.72 95cnfr9u0.net
ANSI C以前のC処理系で、frexp()の第2引数が、intではなくdoubleへのポインタになってるやつってありましたっけ？
176:デフォルトの名無しさん
25/11/20 08:57:49.57 o66Cu/z90.net
>>175
無いです
177:デフォルトの名無しさん
25/11/20 10:19:51.08 WN+N3a+40.net
intで足りなくなったときに便利
178:デフォルトの名無しさん
25/11/21 10:02:41.70 VM+m9mUGa.net
doubleの方が有効桁数少ないんじゃね
179:デフォルトの名無しさん
25/11/21 10:06:53.94 VM+m9mUGa.net
>>173
>Windows に readdir は無いので FindFirstFileW, FindNextFileW を使うのが普通の方法。
もちろんそうだろうと思う有難う
だが WideCharToMultiByte とか MultiByteToWideChar をちょっとすっ飛ばしたかったんだ
180:はちみつ餃子
25/11/21 11:13:01.47 G3R9bFuG0.net
>>179
Windows アプリケーション内部では UTF-16 で扱って、必要なら入出力のときに変換するというのが楽だよ。
モードの設定 (前述の _setmode) をしておけば入出力のときの変換は勝手にやってくれて明示的にプログラマが何かする必要がない。
Win32 API (64ビット版を含む) は UTF-16 が基礎なのでそれで統一しておけば文字コード変換が必要な場面は生じない。
マルチプラットフォームだとかサードパーティー製ライブラリと組み合わせるだとかし始めると色々と困ることもあるし、全体の設計は状況によるんだけど……
181:デフォルトの名無しさん
25/11/22 01:33:08.03 CDycBrMu0.net
>>177
doubleの指数部11bitだったはずなので返る指数は±2**10-1 = ±1023の範囲だ
最低で±32767の範囲を表現できるintがあれば常に十分なはず
よってfrexpのexpはint型のみでいい>>175
182:デフォルトの名無しさん
25/11/24 09:05:52.94 StdCmM8J0.net
long longでいいじゃん
183:デフォルトの名無しさん
25/11/25 10:15:11.74 F0vSFTML0.net
frexp() の第2引数ってそもそも性質からして整数以外有り得ないんじゃね
むしろ第1引数も整数でも良いくらい
184:デフォルトの名無しさん
25/11/25 12:28:06.26 MC0j4mydM.net
複素数に拡張してくれ
核開発に使える
185:デフォルトの名無しさん
25/11/25 13:48:33.82 rSIO8n1ld.net
質問です
int hoge(wchar_t *p);
な関数があって
int a = hoge(L"fuga"); だと正常で
int b = hoge("fuga"); だと誤動作します
理由は判りますが
そもそも引数がcompile errorにもwarningにもなりません
C++みたいにcompile errorにする方法は？
186:はちみつ餃子
25/11/25 15:48:36.00 evMdha/k0.net
>>185
規格合致プログラム (conforming program) ではないので許容するとしたら処理系の拡張。
主要な処理系ではエラーになると思うけど、なんていう処理系を使ってるの？
187:はちみつ餃子
25/11/26 10:42:02.61 ZGYu6bhA0.net
念のために仕様をよく読んで検討したら wchar_t が char の別名として定義されることは理屈の上では認められることを発見した。
そしてその上で文字列リテラルとワイド文字リテラルが異なる符号体系を持つということも可能ではある。
もしそういう処理系なら >>185 の事例は型が合った上で誤作動 (プログラマの想定と異なる動作) を引き起こすかもしれない。
実際にそういう処理系があるのかどうか知らんけど libc のドキュメント中で組み込みシステムではそういうのも妥当かもしれないという言及がある。
URLﾘﾝｸ(www.gnu.org)
188:デフォルトの名無しさん
25/11/26 11:37:21.77 g4n+mUAPa.net
>>186
ＶＣで確認したら警告は出たがエラーではないので実行出来た上で誤作動（描かれた通りには動いている）
警告レベル替えればエラーにも出来るんだろうけど
文字列リテラルポインタからワイド文字列リテラルポインタへの自動キャスト（あるいはその逆のキャスト）以外のところにも影響出てエラーだらけになるかも
文字列リテラルポインタからワイド文字列リテラルポインタへの自動キャスト（あるいはその逆のキャスト）限定でエラーにならないかな
189:はちみつ餃子
25/11/26 15:23:02.27 ZGYu6bhA0.net
>>188
MSVC がそんな馬鹿げた仕組みとは驚きだな。
合わない型 (本来は暗黙の型変換も認められない型) は一律にエラーになるべきだけれど、とりあえず自分のコードで型が合わないケースをエラーにしたいなら
#pragma warning(error : 4133)
とするくらいが落としどころじゃないかと思う。