C言語なら俺に聞け 164

2025/11/12(水) 23:55:46.80

ここでおそらく、tarでアーカイブし、ディレクトリ名が重複するので端折る事を想定していると思われるが、
これは間違いだ。『ディレクトリ文字列』ではなく、単純に『文字列』を端折るだけでいい。
つまり、

ファイルシステム上：
./pathA/pathB/hoge.txt
./pathA/pathB/hogehoge.txt
./pathA/pathB/hogehogehoge.txt

はちみつ式tarアーカイブ：(ファイル名先頭に同一『ディレクトリ』かマークする＝デリミタ文字を認識しないといけない)
(新)./pathA/pathB/hoge.txt
(同)hogehoge.txt
(同)hogehogehoge.txt

俺式tarアーカイブ：(直前レコードと『文字列が』頭から何文字同じかマークする＝デリミタ文字を気にする必要ない)
(0)./pathA/pathB/hoge.txt
(18)hoge.txt
(22)hoge.txt

この例は偶々、俺式の方が圧縮出来るが、実際はこんな都合のいいファイル名並びはほとんど無い。
マークサイズが、はちみつ式はbool、俺式はint(またはshort/char)なので、実際にどちらが小さいかは場合によりけりだろう。
ただポイントは、俺式はファイルのデリミタ文字がMには関係ないところだ。
Mはただの倉庫であって、文字列→中身、が出来れば十分で、外部の仕様には一切依存しない、ということ。
(はちみつ式はデリミタが/であるunix仕様がMに癒着している。とはいえこれが問題になる事はまずないはずだが)

2025/11/12(水) 23:59:23.72

書けない？テスト

2025/11/13(木) 00:02:39.38

あと2投(44行)あるが、規制された？ので、しばらく後に投稿する

2025/11/13(木) 00:14:22.09

うむ、書けんな。まあ>>135は正しいが

2025/11/13(木) 07:23:44.03

staticオジサン居る？
カプセル化で、ダイレクトに非staticプロトタイプで関数コールしている？
あるいは、typedef struct { void (*polling)(bool *tick) } Txxx;のように構造体の関数ポインター経由でコーールしている？
InitializeコールしないでNULLポインターをコールすることもあるのが難。
構造体の方がアプリトップレベルのBinderで管理できるので良いように思えるが、いまいち悩むところ。

2025/11/13(木) 07:26:01.38

やはり書けないっぽい
行数制限か？
しばらくチマチマ試すが、駄目だったら諦めで

2025/11/13(木) 07:33:41.70

ここで先述の通り、M-Vインタフェースは文字列『全体』、つまり、
(18)hoge.txt から ./pathA/pathB/hogehoge.txt に戻す部分は、M側に持たせる。

2025/11/13(木) 07:37:32.03

んー、行数ではなく文字数制限か？
しかしバラバラだと読みにくすぎるので、また後日試すわ

2025/11/13(木) 07:59:27.63

Mangoで試して一部バラバラにすれば行けそうなので落とす。内容は以下と同一
https://agree.5ch.net/test/read.cgi/mango/1754986690/92-98

2025/11/13(木) 08:00:05.36

これにより、M側はsqliteと

2025/11/13(木) 08:00:31.21

交換可能になり、(DB/KVSの場合は上記ファイルシステム上の文字列そのままがキーになる)

2025/11/13(木) 08:00:57.42

アーカイブして戻すだけではなく、ライブファイルシステムとして使えるようになる。
これはsqlite公式でも言っている通り、
> https://sqlite.org/fasterthanfs.html
現在のブロックファイルシステムにおいては最低限4K食うので、小さいファイルが沢山の場合にはsqliteの方が効率がいいから。
(GUIが無いという話はあるが…まあexplorerでzip開けるあの感じがベストだとは思うが)

そしてVだが、順当に考えれば、キー(≒ファイル/パス/URI)については、
V0: unix用UI: 何もしない
V1: Windows用UI: \を/に変えて記録、/を\に変えて戻す(トークン分割ではなく、単なる文字置換)
V2: Web用UI: 何もしない
が妥当だろう。
各Vはそれぞれ使えない文字が異なるので、Mからその文字列が来たときにどう扱うかは各Vに任せる。
これでシステム間もあっさり解決だ。
ポイントは、保存対象が何であれ、Mの中身は同じで、M-Vインタフェースも同じ、ということ。
そして繰り返すが、トークン分割の必要はない。もっと初歩的な、文字置換だけで済む。

2025/11/13(木) 08:01:38.94

つまり構成としては、
M(sqlite): sqliteそのままでいい。
M(俺式tar): トークン分割は必要ない。
　(18)hoge.txt から ./pathA/pathB/hogehoge.txt に戻す文字列操作は、数えて、concatするだけ。
　\の検索も要らない。
であり、Mでの文字列操作は、必要ないか、極単純か、となる。

一方Vは、はっきり言ってCで作る意味がない。(高速/最軽量のCを生かす事は出来ない)
unixならシェルで作ればいいだけ。
sqliteはシェルからそのまま扱えるらしいので、
> sqlite3 データベースファイル名 < スクリプトファイル名
> https://iifx.dev/ja/articles/123001461/sqlite3スクリプトをコマンドラインで華麗に操る方法
find . -print の結果を適当にゴニョゴニョすればまあ行けそう。
Blobをどうやって作るのかは知らんが、多分手段はあるのだろう。(いい加減面倒になってきた)

Windowsでも、powershellで何とかなるんじゃね？駄目なら.NETでいいし。
どのみち、CでVを作る必要はない。
Cで作るのはMだけでよく、Mではなるべく文字列操作をしない、またはしなくて済むように設計する。
V部分は各環境の便利なものを使い、そこでファイル/文字列操作はやってしまう、という事。

というわけで、例外/抽象化/隠蔽/MVC等と言っておきながら、MVCしか説明出来てないが、面倒なのでこの辺で止める。
馬鹿に一々付き合ってても、ネットでは無限に馬鹿が沸くので、キリがない。
お前らが俺以上に手間を掛けたと分かる場合のみ相手するが、おそらくこれはないはず。
そしてこれ以上お前らが馬鹿こいても無視するのでよろしく。
無知のままで居るのもお前らの自由ではあるし、本当にキリがないので。

2025/11/13(木) 08:02:19.41

以上、終わり

2025/11/13(木) 15:04:26.13

>>136
支離滅裂で何ひとつ伝わっていないとだけ言っておく。
意味がわからないのでこれ以上は反応しない。

2025/11/13(木) 20:55:40.45

>>153
俺が新しく展開した話に対し、どう捉え、どう振る舞うかはお前の自由だ。
ただ、不十分であれ、俺はお前の質問/議論に対応しようとしたのだから、
お前も俺の質問、再掲するが以下には、同程度の対応をする義務はあると思うがな。
回答しないのなら、俺も今後はお前の質問>>129に対しての回答>>130すらも遠慮させて貰う。

>>133
ただその前に、
> 常に明示的にユーザが名前を与えるべきというのはナンセンスだ。
「名前」とは何ぞ？

2025/11/13(木) 22:45:21.40

>>143
言いたいことがよくわからん (非staticプロトタイプってなんや？) けど私なりに推測するとカプセル化の基本パターンや使い分けが知りたいってこと？

2025/11/14(金) 10:11:22.08

「モバイルオーダー」悪用、１万円超の弁当代を５８円で不正決済…２３歳の無職男を容疑で逮捕

決済システムが脆弱すぎだろ？
よくこんな作り方で普及させたな？インド人か？

2025/11/14(金) 11:20:09.02

一万円の弁当か、食べてみたい
払う気はないけど

2025/11/15(土) 03:54:57.59

あら　C99で空宣言使えなくなった？

typedef enum {} PINSTATE;

typedef struct s_pinobj {
bool(*sequence)(struct s_pinobj * obj);
uint16_t tickcount; // 10ms ticking
PINSTATE state;
.
.
} TXXX;
などと使っていたんだけど、エラーになるようだ。
循環参照対策はどうするんだろ？

2025/11/15(土) 08:31:52.06

客→クレジット会社鯖→決済情報→商店
の流れを

客→決済情報→商店
だとよ

つまりクレジット会社鯖でやってる業務をすべてなりすまししてるわけだ
鯖と商店とのやり取りもザルだったってこと

2025/11/15(土) 11:24:07.72

>>158
空宣言というのは enum の列挙子がゼロ個ということを言ってるの？
enum が導入された C89 の時点で列挙子はひとつ以上が必要ということになっていて列挙子がゼロ個で良かった時代は無い。
(出来たとしたら処理系の拡張。)

そして enum の宣言は必ず列挙子のリストを必要としている。
struct のように { } を書かなければ不完全型として宣言されるというようなことはないから前方宣言で名前だけ書いておいて後で中身を定義するということも出来ない。
不完全型の列挙型というものは存在できないってことね。

2025/11/15(土) 11:40:24.78

>>159
普通は後にこんな流れが加わってるはず
商店→クレジット会社→決済情報コンペア→決済確認→商店→決済完了

2025/11/15(土) 14:39:56.35

>>161
そうなってないから決済が完了し、商品が届けられて犯罪成立しちゃってる

あとになって入金が合わずに発覚しただけだからなぁ

2025/11/15(土) 15:15:39.55

>>162
システム考えた奴、頭悪いのかなぁ？
暗号化とか過信したのかなぁ？

2025/11/15(土) 15:38:28.29

例え決済情報を盗まれてもさ、アクセス先がクレジット会社でもないとこからのやつを
なんで正規なものとして受け取るかね？
いろいろおかしい

2025/11/17(月) 21:52:49.67

C言語とは直接関係ない話題だが、
カード情報が盗まれてそのまま決済が
通過してしまった事件が過去にあった。
カード持ち主には返金されたが、
損害を誰が負担するかで揉めてた。
カード会社が持つケースもあったが、
テナント企業が弱いと、涙を流すケースもあった。

2025/11/17(月) 21:56:21.37

直接どころかまったく無関係で草

2025/11/18(火) 00:14:16.54

Eコマースサイト作る上では必要な知識だからな
全く無関係って訳ではない

2025/11/18(火) 00:20:37.35

Cで作るの？

2025/11/18(火) 16:36:11.76

cのcgiだって可能だしあってもいいだろ（？）

2025/11/18(火) 23:45:44.92

windows で
setlocale(LC_ALL, "ja-JP.UTF8"); とか
setlocale(LC_CTYPE, "ja-JP.UTF8"); とか
プログラムの先頭で設定しても無駄？
console は chcp 65001 してる
fopen() のファイル名に UTF8 で渡したいんだが
出来れば readdir() も UTF8 で取得したいのよ

2025/11/19(水) 07:24:28.12

ソースコードがSJISなら無駄

**デフォルトの名無しさん** (ｽﾌｯ Sd22-A2v6) · 2025/11/19(水) 10:44:13.50

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.

2025/11/19(水) 11:29:22.16

>>170
普通の入出力はテキストモードとバイナリモードがあって、ロケールの設定がテキストモードの振る舞いに影響するんだけど……
Windows の場合はテキストモード・バイナリモード・ユニコードモードに分かれていて _setmode でユニコードモードに設定する必要がある。
しかしユニコードモードの設定はワイド入出力系関数 (wprintf など) にしか影響を及ぼさない。

そんでその辺の設定をしても、入出力の内容に関してであってファイル名を UTF-8 で渡すのはたぶん駄目なはず。 (確認はしてない。すまぬ。)
ファイル名はワイド文字 (UTF-16) に変換してから _wfopen で開くのが正当な方法だと思う。

Windows に readdir は無いので FindFirstFileW, FindNextFileW を使うのが普通の方法。

だいぶん前に調べたときは msvcrt と ucrt でちょっと振る舞いが違ったような記憶があるのでそこらにも注意が必要。
ucrt は色々と大きく改良されているみたいなのでひょっとするともっとモダンな方法があるかもしれない。

2025/11/19(水) 12:12:33.50

UTF16は廃止してほしい

2025/11/19(水) 13:55:46.72

ANSI C以前のC処理系で、frexp()の第2引数が、intではなくdoubleへのポインタになってるやつってありましたっけ？

2025/11/20(木) 08:57:49.57

>>175
無いです

2025/11/20(木) 10:19:51.08

intで足りなくなったときに便利

2025/11/21(金) 10:02:41.70

doubleの方が有効桁数少ないんじゃね

2025/11/21(金) 10:06:53.94

>>173
>Windows に readdir は無いので FindFirstFileW, FindNextFileW を使うのが普通の方法。
もちろんそうだろうと思う有難う
だが WideCharToMultiByte とか MultiByteToWideChar をちょっとすっ飛ばしたかったんだ

2025/11/21(金) 11:13:01.47

>>179
Windows アプリケーション内部では UTF-16 で扱って、必要なら入出力のときに変換するというのが楽だよ。
モードの設定 (前述の _setmode) をしておけば入出力のときの変換は勝手にやってくれて明示的にプログラマが何かする必要がない。
Win32 API (64ビット版を含む) は UTF-16 が基礎なのでそれで統一しておけば文字コード変換が必要な場面は生じない。

マルチプラットフォームだとかサードパーティー製ライブラリと組み合わせるだとかし始めると色々と困ることもあるし、全体の設計は状況によるんだけど……

2025/11/22(土) 01:33:08.03

>>177
doubleの指数部11bitだったはずなので返る指数は±2**10-1 = ±1023の範囲だ
最低で±32767の範囲を表現できるintがあれば常に十分なはず
よってfrexpのexpはint型のみでいい>>175

2025/11/24(月) 09:05:52.94

long longでいいじゃん

2025/11/25(火) 10:15:11.74

frexp() の第2引数ってそもそも性質からして整数以外有り得ないんじゃね
むしろ第1引数も整数でも良いくらい

2025/11/25(火) 12:28:06.26

複素数に拡張してくれ
核開発に使える

**デフォルトの名無しさん** (ｽﾌｯ Sd7f-Lg42) · 2025/11/25(火) 13:48:33.82

質問です
int hoge(wchar_t *p);
な関数があって
int a = hoge(L"fuga"); だと正常で
int b = hoge("fuga"); だと誤動作します
理由は判りますが
そもそも引数がcompile errorにもwarningにもなりません
C++みたいにcompile errorにする方法は？

2025/11/25(火) 15:48:36.00

>>185
規格合致プログラム (conforming program) ではないので許容するとしたら処理系の拡張。
主要な処理系ではエラーになると思うけど、なんていう処理系を使ってるの？

2025/11/26(水) 10:42:02.61

念のために仕様をよく読んで検討したら wchar_t が char の別名として定義されることは理屈の上では認められることを発見した。
そしてその上で文字列リテラルとワイド文字リテラルが異なる符号体系を持つということも可能ではある。
もしそういう処理系なら >>185 の事例は型が合った上で誤作動 (プログラマの想定と異なる動作) を引き起こすかもしれない。

実際にそういう処理系があるのかどうか知らんけど libc のドキュメント中で組み込みシステムではそういうのも妥当かもしれないという言及がある。
https://www.gnu.org/software/libc/manual/html_node/Extended-Char-Intro.html#index-wchar_005ft

2025/11/26(水) 11:37:21.77

>>186
ＶＣで確認したら警告は出たがエラーではないので実行出来た上で誤作動（描かれた通りには動いている）
警告レベル替えればエラーにも出来るんだろうけど
文字列リテラルポインタからワイド文字列リテラルポインタへの自動キャスト（あるいはその逆のキャスト）以外のところにも影響出てエラーだらけになるかも
文字列リテラルポインタからワイド文字列リテラルポインタへの自動キャスト（あるいはその逆のキャスト）限定でエラーにならないかな

2025/11/26(水) 15:23:02.27

>>188
MSVC がそんな馬鹿げた仕組みとは驚きだな。
合わない型 (本来は暗黙の型変換も認められない型) は一律にエラーになるべきだけれど、とりあえず自分のコードで型が合わないケースをエラーにしたいなら
#pragma warning(error : 4133)
とするくらいが落としどころじゃないかと思う。

**デフォルトの名無しさん** (ｽﾌｯ Sd7f-Lg42) · 2025/11/27(木) 05:19:27.44

ありがとうございます
>>188
よくみたらwarning出てたのみのがしてました
>>189
良い感じにcompile errorにしてくれました

2025/11/29(土) 18:02:47.96

固定小数点でも誤差が出ます
とかトンチンカンなこと言い出すやついるけど
割り算しなきゃほぼ誤差ないんだよ

2025/12/01(月) 12:04:42.29

gmp使ったソースだった