C言語なら俺に聞け 164

2025/07/23(水) 15:30:01.81

(新スレ立ての際上記コマンドを2行書き込んでください)
C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C17
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4713.pdf

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C23 最新ドラフト
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3047.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

※前スレ
C言語なら俺に聞け 163
https://mevius.5ch.net/test/read.cgi/tech/1721137434/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2025/10/15(水) 18:45:39.97

まあ趣味で一つプログラムするならなんでもいいけど
ある程度量産するならコスパが十倍-百倍違うのは致命的

2025/10/15(水) 20:40:36.66

>>63
多すぎる。
512Bとか256B（1kBすらも無い）とかがＣやアセンブラしかない世界。

2025/10/16(木) 18:01:41.31

我が家みたいだ

2025/10/16(木) 18:37:01.53

>>66
そのマイコンの型番教えてくれ

2025/10/16(木) 20:29:12.39

マイコンってかマイクロコントローラーだけどPICとかAtmelとかでいっぱい見かけるよ。
１個10円とかのは大体マイクロコントローラー。
秋月電子のストアならデータシートのPDFをDL出来るんで、細かい仕様はそれを見る。

2025/10/17(金) 00:24:14.63

>>68
https://akizukidenshi.com/catalog/g/g104575/
↑とか
https://akizukidenshi.com/catalog/g/g127731/
↑とかRAM控えめだぞ

2025/10/18(土) 01:03:37.15

>>66
そんなんじゃprintfすら作れないよｗ

2025/10/18(土) 04:22:07.50

シリアルコンソールもない規模なのにどこにprintfするんだ

2025/10/18(土) 06:34:34.64

いまだにprintfデバッグやってるジジイ

2025/10/18(土) 11:43:31.92

> 256B
関数（サブルーチン）1個作って終了だな。

2025/10/18(土) 12:08:07.87

>>63
Cマガの付録のLSI-C試食版ではタイニーモデルは出力できなかったな

2025/10/18(土) 12:10:03.61

メモリが64Kではタイニーも動かないか…

2025/10/18(土) 12:34:26.68

>>73
gdbも使いはするが
ちゃんとfflushするか、ちゃんとstderrへのfprintfで記録取る限りにおいて、printfデバッグは今でも十分役立つと思うが
むしろデバッガと相補的

2025/10/18(土) 12:40:57.58

>>69
個人趣味レベルでもある程度量産することはあるからね
マイコン価格には十円単位で気を使ってるよ
あなたのいうPICキットには1台で次々沢山焼く機能あるしな、数百個くらいは余裕
>>65だけど100個焼く石がもし数百-千円クラスなら普通に万-10万消えて泣ける

2025/10/18(土) 13:05:23.67

量産して売るのか？

2025/10/18(土) 13:10:13.42

いやプロとかしゃなくて同人即売会で売るレベルですはい
それでも百個くらいは要るでしょ

2025/10/18(土) 14:09:15.39

デバッグは、Lチカの有無で地道にやるんだよな

2025/10/19(日) 19:31:28.29

>>66
コードセグメントデータセグメントが1kb単位でしか指定できなくて発狂

2025/11/08(土) 09:43:07.20

C99はitoa無くなったん？　なんで？

2025/11/08(土) 10:25:48.38

>>83
無くなったというか規格に入ったことはないはず。
POSIX (やその後継である SUS) にも無い。

2025/11/08(土) 10:47:36.79

そもそもCで文字列操作する気にならない

2025/11/08(土) 10:57:45.77

でもUNIXのI/Oは基本バイトストリームで文字列指向だから切り離せないでしょ？
基盤やライブラリがやることだから低レベルに書きたくないんならわかる

2025/11/08(土) 11:15:17.81

C全盛期にインターネットが一般的になってたら
有名なライブラリがその辺りを補完しまくってくれたのかなぁ

2025/11/08(土) 12:09:11.14

>>85
ACSIIで固定長なら何も問題ない。そしてbash等はそれで出来てた。
utf-8で可変長(＝今の一般的なstring)なんてCでやると死ねるだけ。

2025/11/08(土) 14:42:52.89

スクリプトで処理することも多いし
基本は文字列で扱うな

2025/11/08(土) 16:40:45.22

itoa() というか、数値から文字列への変換となると文字列の長さがどうなるか分からないから消滅したのでは？
かといって sprintf() は健在だが、おすすめは snprintf() だな。(GNUだと asprintf() ってのもあるな)

2025/11/08(土) 18:49:14.49

sprintfのbuffer*にヌルポを指定するとbufferに書き出さず単に出来上がり文字列の長さだけ返す、
みたいな仕様があったと思ったが、かなり特定環境の話かこれ？
(他関数と勘違いしてるかもだが、思い出せないし、ググッてもよく分からん)

2025/11/08(土) 19:24:13.72

snprintfの返り値がそういう動作だから
長さだけがほしいときヌルポじゃなくバッファ長を0にする
manpageを信用するとだいたいは叶うけど昔のSUSv2ではエラーと書いてるね

2025/11/08(土) 20:00:28.59

それは多分、推奨が変わって、それに合わせてmanページも書き換えられただけではないかと。
MSにはscprintfという、長さだけを返す関数が用意されている。
(s*printfのbufferがヌルポだとエラー、おそらく型チェックを厳しくする為に分離したのではないかと)
https://learn.microsoft.com/ja-jp/cpp/c-runtime-library/reference/scprintf-scprintf-l-scwprintf-scwprintf-l?view=msvc-170

2025/11/09(日) 15:49:06.10

長さって言うと、バイト数か文字数かで悩む

2025/11/09(日) 15:56:50.51

マルチバイト文字なんてC言語が考慮してるはずが無いだろ
全部外部関数だからなあれら

2025/11/09(日) 17:54:10.57

どの範囲が内部関数なんでしょうか？

2025/11/09(日) 18:08:54.56

stdio.h等、K&Rに記載されてる範囲じゃね？
(勿論sprintfも記載あり)

2025/11/09(日) 18:38:57.72

こういうときK&R持ち出してくる意図がわからん
80年代で頭が止まってるのか愉快犯なのか

2025/11/09(日) 19:57:32.76

俺は80年代で頭が止まってるが、K&Rは今でも名著で読む価値があるのも事実だろ
(というかCが変わって無さ過ぎなだけだが)
Zにはドラゴンボールハラスメントなのかもだが

2025/11/09(日) 20:21:54.18

今どきK&Rかよ! てのは昔からいる。超カンタン○○言語なんてのを有り難がるのだけど、なぜか原典の類いには絶対当たらない。

2025/11/09(日) 20:36:39.24

得る知識量/文字数、というZ的コスパなら、K&Rに勝る本は他のプログラミング言語含めても無いよな
その分端折りまくりだし、そもそも既にプログラミング出来る人向けに書かれているので、初心者には向かないが

しかし本来は、K&Rに勝る本を誰かが書いて、葬ってやるべきなのだろうけど、
あれ以上エッセンスだけ凝縮するのも無理よねって事で今に至るわけだし

2025/11/09(日) 20:48:05.83

標準ライブラリの話なのに何とんちんかんなこといってんの
準拠してる規格か処理系そのものに依存するから古典みてもわからんでしょ
当時の知識でもヘッダやライブラリの場所から当たりはつくけどな

2025/11/09(日) 20:58:39.28

>>102
ならお前が>>96に対する、俺より分かりやすい回答を出せば済んだ話だろ
それもせず、とんちんかんな方向のレス付けたのはお前自身なのに、他人のせいにする所はＺ仕草か

まあ話を戻す気があるなら、とりあえず>>96に回答して、その分かりやすさを俺97と競うべきだよ
それも出来ないなら、ああやっぱりＺは、と言われ続けても仕方ないだろうよ

2025/11/09(日) 21:03:11.42

K&R馬鹿にしてるのもZ連呼してるのも傍から見てたらどっちもアホですわ

2025/11/09(日) 21:10:40.56

バカにはしてないむしろ信奉者だし
アホなのはそのとおり
ウソが知識不足からか故意なのか気になっただけ
書けば質問者への気づきにもなるしな

2025/11/09(日) 21:24:36.18

>>104
だからそういうのは要らねえから、さっさとお前流の>>96に対する回答を書いて勝負すればいいわけ

というかね、完全に脱線するが、
例の非韓三原則「韓国人には、教えない、助けない、関わらない」とか、
Kの法則、「韓国(人)に関わると不幸になる」というの、ありゃ何だろうなと思ってたんだが、
数年前には俺なりに結論が出てしまった

あれはな、連中は、「自分を上げるのではなく、他人を下げる事」しかしないからなんだ
そして、ゆとりやＺも同様の傾向があるから、そうならないように意識して注意した方がいい
それはお互い足を引っ張り合ってるだけであって、高める方向ではないから

今回もそうだろ、他人にケチを付けるだけで、自分でよりよい回答を出そうとはしない
だから結果的に、よりよい回答を得られる機会を失い、罵りあう状況を生み出してる
受け方を間違えなければ本来プラスに持っていけた所が、マイナスになってしまってる
ここら辺が、ゆとりやＺがコミュ障で困る部分なんだよ

だからお前達は自分達世代だけではマトモに会話出来る場所を持てず、
年上世代が蔓延る5chに寄生するしかなくなってる
その辺もちゃんと自覚した方がいい

5chで偉そうに講釈垂れつつ、裏で必死にググって理論武装しつつ、という俺ら世代の馬鹿共も、
この点はゆとりやＺとは正反対で、きちんとプラス方向に寄与してたわけ
だから5chは生き残って来れてるわけでね

>>105
同上。

2025/11/09(日) 21:55:55.88

そもそもCで外部内部関数なんて概念がナンセンスだろ

2025/11/09(日) 22:22:11.91

>>107
今回の文脈は、

94: マルチバイト文字ガー
95(≠俺): それらは全部外部関数（≒内部関数はシングルバイト対応のみ)
96: なら内部関数ってどこまで？

なので、馬鹿でなく、正面から乗ってやるなら、お前なりの線引きを答えてどうぞ
質問が無効なので回答しようがない！ってのは、スカしてイケてるつもりの馬鹿がよくやるパターンだ
こいつらも、コミュ的には迷惑なだけ
95の「外部関数」が問題だとするなら、
95よりも分かりやすく、95の代替になる回答を用意するように心掛ければ済むだけ
出来ないのなら、黙っておく方がいい
C言語の仕様として「内部/外部の区別がない」とか、別方向にウンチクを垂れるのならどうぞだが

2025/11/10(月) 07:43:17.41

これだからＺは。

>>98は自ら意図的に世代間抗争に持ち込んでいるのに、ケツも拭けないのか
ゆとりＺはやはり死ねだな
5chが(俺ら世代にとって)比較的マシな場所なのは、ゆとりＺの存在確率が低い事が地味に効いてる
理解出来てない奴の方が多いけどね

世代間抗争も、やりたければやればいいと思うが、せめて勝てる算段を立ててからにしろよと
コミュ障がコミュ障のままなのは、結局の所、コミュ上手になろうともしてないからだ

2025/11/10(月) 11:26:46.51

初老が中年にマウントとるスレ

2025/11/10(月) 14:39:59.87

いくつから中年ですか？

2025/11/10(月) 15:24:22.95

switch(年齢) {
　case 0 ... 7: return 幼年;
　case 8 ... 17: return 少年;
　case 18 ... 25: return 青年;
　case 26 ... 65: return 中年;
　default: return 老年;
}

2025/11/10(月) 15:50:01.90

他言語で”sjisの￥が含まれた全角文字の字化け"で苦しんだ思い出・・・。

2025/11/10(月) 18:58:50.79

大概の言語はsjis扱う方法があるはず

2025/11/10(月) 20:08:23.10

>>110
ゴミクズ若害ゆとりＺが老害マウントを取り損なったスレだな
ただ>>98はRustに行った方が幸せになれるとは思う

2025/11/11(火) 01:27:33.54

LinuxでMicrosoft C拡張が使える様になるらしい

2025/11/11(火) 08:58:14.69

>>116
わららない。レベルが低くてスマソ

Microsoft C拡張ってこれ?

https://learn.microsoft.com/ja-jp/cpp/build/reference/microsoft-extensions-to-c-and-cpp?view=msvc-170
> C および C++ の Microsoft 拡張機能

Linux 上の MS コンパイラか何かがあるの?

2025/11/11(火) 14:43:16.54

ディレクトリを/で分割したいときstrtokで出来そうだけど
\で分割したいときstrtok使うとsjisのとき困りませんか？
文字列じゃなくディレクトリとして扱う標準関数ってどんなのがある？

2025/11/11(火) 15:13:06.91

そんなクソプラグラムいつまで作ってんだよ

2025/11/11(火) 15:19:43.32

>>118
sjis扱うならそれがマルチバイト文字の一部か１バイト文字かを判定するのが普通では？

2025/11/11(火) 17:21:20.49

自分はではないけど、ShiftJisで1バイトではなく1文字戻る場合、1バイト目なのか2バイト目で1バイト目と被る部分なのかがわかりにくいよね

2025/11/11(火) 17:28:31.16

自分はではないけど
↓
自分は118ではないけど

2025/11/11(火) 18:20:54.06

>>118
> strtok
クソ仕様過ぎてビビる
使うの止めた方がいいのでは？

2025/11/11(火) 18:21:45.51

>>121
> 先頭から文字コードの判定をする場合はよいが、
> 後ろから判定をしようとすると、最悪の場合、先頭までたどらないといけないことがある (from wiki)
仕様外(製作時の想定外)だから諦めて、インデックス作るか、16bit固定長やutf8に変換するのが吉かと

2025/11/12(水) 07:37:37.89

1文字づつ属性タグ付けてから好きな処理すればいい

2025/11/12(水) 09:44:34.01

>>118
標準関数というのが言語仕様 (規格) にある関数という意味ならディレクトリという概念すら無い。
ファイルを指し示す文字列は単に「ファイル名」としか書いておらず、どういった形式を持つかは規定されない。
ファイルシステムによって独特の概念がある場合もあるし、言語仕様で決めるような筋合いのものではないってことだと思う。

ホスト環境 (OS) のほうでなんらかの機能を提供している場合もあり、たとえば Windows だと shlwapi.h にある名前が Path で始まるやつはパス操作関係の API だ。

2025/11/12(水) 11:47:07.85

DOS時代は文字コードをASCII、JIS/SJISしか知らなかったから
文字列操作は1字2バイトにする関数作って自分で処理してたな。

2025/11/12(水) 12:45:29.14

それで正しいよ

そもそも118の必要有ったっけ？と思ってfopen見たら、やっぱりフルパス受け付けるじゃん
Cでやるべき事と、やるべきでない(やる意味もなく、やっても無駄に嵌る)事を区別出来てないだけ

2025/11/12(水) 13:00:11.37

>>128
意味が分からない。
この場合にフルパスがどうこうというのはどのように関係してくる？

2025/11/12(水) 14:04:58.47

>>129
データ処理(fopen)したいのならディレクトリ区切り文字なんて気にする必要なく、そのままフルパス文字列を全部与えればいい。
だから118の処理をCで自前でやる事自体がナンセンス。
そのコードはその処理系が用意したfopen内に存在している。(か、そもそも必要ないか)

シンボリック/ハードリンク等のファイルシステム固有の件をおいておくとすれば、
ファイルシステムは、フルパスをプライマリキーとしたDBとして抽象化出来る。
そのプライマリキーの正規化や探索方法はDB(システム)側の事情であり、ユーザーが処理するべきではない。

つまり、ユーザー側は、入力されたパス/ファイル名文字列をそのままfopen等システム側に食わせるべきであって、
118の様に、自前で加工するべきではない。
勿論、お前の言うように、C自体にはディレクトリの概念すらないのだから、
Cでexplorerじみた物を作るにしても、「標準関数」ではなく、
例えばWindowsなら.NET等、環境が用意した関数群を使えば最初から何も問題が発生しない。

具体的に言った方が分かりやすいかな？
例えばunix環境だと//は/扱いになるはずだが、この辺も全部ご丁寧に実装していくつもりなのか？
(他に何が有るのかは知らんが、たぶんあるのだろうし)
或いはutfでは毎度言われてるMacの正規化がおかしい件
https://applech2.com/archives/20251106-time-machine-bug-still-unresolved-on-macos-26-1-tahoe.html
この辺も全部引き受けるつもりなのか？
こんな事やり出したら泥沼に嵌るのは間違いないので、118の設計思想にバグがある。
入力文字列そのままでファイルを探索出来ないのなら、エラーを返し、使用者に再入力させる実装の方が一般的に正しい。
(これを綺麗にやるのが例外システムだが、Cには例外がないので、
美しさに拘るなら、ファイルオープンまでは他言語でやって、実処理部分だけCのdllを呼ぶのがいいと思う。
Cしか書きたくないなら、一番近いのはVC++だろうよ)

2025/11/12(水) 14:04:58.47

>>129
データ処理(fopen)したいのならディレクトリ区切り文字なんて気にする必要なく、そのままフルパス文字列を全部与えればいい。
だから118の処理をCで自前でやる事自体がナンセンス。
そのコードはその処理系が用意したfopen内に存在している。(か、そもそも必要ないか)

シンボリック/ハードリンク等のファイルシステム固有の件をおいておくとすれば、
ファイルシステムは、フルパスをプライマリキーとしたDBとして抽象化出来る。
そのプライマリキーの正規化や探索方法はDB(システム)側の事情であり、ユーザーが処理するべきではない。

つまり、ユーザー側は、入力されたパス/ファイル名文字列をそのままfopen等システム側に食わせるべきであって、
118の様に、自前で加工するべきではない。
勿論、お前の言うように、C自体にはディレクトリの概念すらないのだから、
Cでexplorerじみた物を作るにしても、「標準関数」ではなく、
例えばWindowsなら.NET等、環境が用意した関数群を使えば最初から何も問題が発生しない。

具体的に言った方が分かりやすいかな？
例えばunix環境だと//は/扱いになるはずだが、この辺も全部ご丁寧に実装していくつもりなのか？
(他に何が有るのかは知らんが、たぶんあるのだろうし)
或いはutfでは毎度言われてるMacの正規化がおかしい件
https://applech2.com/archives/20251106-time-machine-bug-still-unresolved-on-macos-26-1-tahoe.html
この辺も全部引き受けるつもりなのか？
こんな事やり出したら泥沼に嵌るのは間違いないので、118の設計思想にバグがある。
入力文字列そのままでファイルを探索出来ないのなら、エラーを返し、使用者に再入力させる実装の方が一般的に正しい。
(これを綺麗にやるのが例外システムだが、Cには例外がないので、
美しさに拘るなら、ファイルオープンまでは他言語でやって、実処理部分だけCのdllを呼ぶのがいいと思う。
Cしか書きたくないなら、一番近いのはVC++だろうよ)

2025/11/12(水) 15:16:59.28

ディレクトリをぶんかつしたいって話にfopenとか何言ってんだ？とおもいました

2025/11/12(水) 15:17:06.90

>>130
たとえば指定されたファイルをアーカイブするときにパスからディレクトリ部分は取り除いて格納するだとか、文字列処理でパスを分解したいユースケースはごく普通にある。
アプリケーション作者が自前でやるのが困難なレベルの複雑な仕様なのであればそれは OS の機能かライブラリとして用意されるべき筋合いのことで、常に明示的にユーザが名前を与えるべきというのはナンセンスだ。

2025/11/12(水) 17:31:16.04

パス名の分解で、0x5cを調べながらあれこれやったけどな。

2025/11/12(水) 23:03:06.47

DOSであれこれパス操作するなら
まずスラッシュに正規化するのがいいんでは？
API(INT)はスラッシュでもそのまま通るし

2025/11/12(水) 23:53:18.57

>>133
それはお前が例外/抽象化/隠蔽/MVC等をまるで理解出来てない馬鹿だからだな。
まあ具体的に話をした方がいいようだから、そうしてみよう。

ただその前に、
> 常に明示的にユーザが名前を与えるべきというのはナンセンスだ。
「名前」とは何ぞ？
ユーザーが常に「フルパスを」与えろという意味なら、これもMVCを理解出来てない故の間違いだ。
そこはV(=UI)で補完するべき部分であって、
M(=本体の内部構造)には関わりない。(というより独立/分離している)

ついでに脱線しておくと、お前が典型的だが、Cの連中も不勉強が過ぎるとは思ってる。
馬鹿にされてるWeb系は、実際馬鹿しか居ないのも事実だが、
それでも回るように出来てる＝馬鹿でも上手く行くシステムが構成されてて、これは学ぶ価値がある。
Cに引き籠もるのもどうぞ御自由にだが、
現在においてそれは、全然効率的でない、生産性の低いプログラミングに留まっている事を自覚しないと駄目だ。
そして、おそらくそういう連中に対して不満があって、
K&R警察と化したゴミクズ若害ゆとりＺ>>98に俺は無駄に噛み付かれた訳だが、とんだとばっちりだ。
98は結局、よりよい回答を出しあう、上方向の競争には参戦せず、
より馬鹿にしあう、下方向の競争しかしなかったわけだから、ゴミクズであることは事実だが、
K&R警察が発生してしまうのは、お前らの問題でもある。

2025/11/12(水) 23:53:46.82

さらについでに言うと、string.hが割とゴミなのは広く言われてるが、
strtokについて問題を感じないのなら、間違いなく無知な馬鹿だ。
(俺は仕様を見た瞬間、え？こんなの許されるのか？と思った)
そしてそれで偉そうにしてるのなら、完全に老害だ。
(だから間髪入れずに叩いた>>119はまあ正しい)

strtokの問題点が分からなければ、使い方を書いたサイトがあちこちにあるからググればいい。
ただ、strtok関しては、使い方を解説するのではなく、使用禁止と明言すべきレベル。
初心者向けのつもりな各サイトなら尚更。
それらに書いてない事を追加すると、
俺はstrtokでは生産性が上がらない(＝使う意味がない)のが駄目だと思っている。
strtokには必ずラッパが必要で、それは使い方サイトに大体出てるサンプルコードになるが、
どうしてもstrtokを使いたい局面では、
そのサンプルコードのstrtok部分を自前でループし、そのラッパ関数を公開した方がいい。
(strtokは関数内関数に留め、グローバルには公開しない)
こうすれば問題の半分は片づく。

ただそもそもCでディレクトリ分割する意味はなく、そのコードを作るのにかけた時間は全部無駄だ。
そのコードは既に他にもっといい出来なのがあるから、それを使うべき。

2025/11/12(水) 23:54:11.21

で、具体的な話をすると、
> 指定されたファイルをアーカイブするときにパスからディレクトリ部分は取り除いて格納するだとか
こんな事する必要ねえんだよ。
お前は具象レベルでしかプログラミング出来ない馬鹿だから、こうとしか考えられないだけ。
モノリシックにしか作れず、特定環境のファイルしか格納出来ないように、無駄に成るだけだろ。
ほぼ同じ手間であらゆる環境で使える物が出来るというのに。

具体的に言うと、この場合は、
M: 内部アーカイブ
V0: unix用UI
V1: Windows用UI
V2: Web用UI
とかに分ける。これでシステム間の引っ越しも余裕になる。
Mは、文字列(キー)→ファイル(値)が引けるDB/KVSなら何でもいい。
最もお手軽には、高速検索/アクセス機能が欲しければsqlite、
レストア出来ればいいだけならtarのようにグチャッとくっつけただけの物となる。
文字列(キー)には、アーカイブしたときのパスをそのまま記録する。
つまり、フルパスで有ればフルパスを、相対パスなら相対パスを指定する。
M-V間のインタフェースはこの文字列『全体』とする。

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

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