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/07/23(水) 15:31:40.26

＞!extend:checked:vvvvv:1000:512
＞(新スレ立ての際上記コマンドを2行書き込んでください)
1行しか書き込まなかった
すまん

2025/07/23(水) 15:50:50.63

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

前スレで補足されてるんだから直しておきなさいよ……。

2025/07/23(水) 16:26:36.12

おー、ごめん

2025/07/23(水) 17:42:37.36

せっかく公式サイトが出来たのに忘れてた……
https://www.c-language.org/

これがあればドラフトを個々に貼るのはやめてもいいかもね。

2025/07/23(水) 19:21:57.84

立て直すのがいいんなら立て直します

2025/07/23(水) 19:49:43.45

ボイス・トォ・スカル自動応答システムが下記でできるようになりました

リアルタイム翻訳の「DeepL Voice」がZoom Meetingsと連携開始、対応言語を拡大
https://news.mynavi.jp/techplus/article/20250723-3387014/

Copilot+ PCに最新のAI機能登場、7月のプレビュー更新プログラム「KB5062660」
https://news.mynavi.jp/techplus/article/20250723-3386867/
>>MicrosoftはWindows Insider Programでテストしていた設定アプリのAIエージェントを正式にリリースした。
※AIで何ができるかを全て書いている

2025/07/23(水) 19:52:38.68

建て直しまでは不要やろ。

2025/07/23(水) 20:08:17.09

・ボイス・トォ・スカルをAIに任せていると誤作動を起こしている
・間違って関係ない人を攻撃し始める

「フクロウ好きなAIが生成した数列」で調整したAIもフクロウ好きになってしまう「サブリミナル学習」が起きる理由とは？
2025年07月23日 19時00分
https://gigazine.net/news/20250723-subliminal-learning-hidden-signals-data/
>>研究チームはサブリミナル学習について調べるための実験を行いました。実験では、まずはベースモデルから「特定の動物が好きな教師モデル」を作成し、数列やコード、思考の連鎖(CoT)といった狭い領域でデータを生成させました。このデータをフィルタリングして特性に関する明示的な言及を除外した上で、生徒モデルのファインチューニングを行い、最終的な生徒モデルがどのような特性を示すのかを評価したとのことです。
>>実験の結果、ファインチューニングに使われたデータには特性への明示的な参照や関連性がないにもかかわらず、生徒モデルは「教師モデルが好きな動物」を好きになることが示されました。
>>研究チームはデータに隠された特性を検出するため、大規模言語モデル分類器や文脈内学習による検出を試みたり、手動でデータを調査したりしたものの、行動特性を伝達している兆候を確認することはできませんでした。これは、サブリミナル学習における行動特性の伝達が、意味的に関連しない生成データ内のパターンに起因していることを示唆しています。

2025/08/20(水) 10:08:45.42

スレ立て乙です

2025/09/19(金) 16:53:51.70

printf("Hello world.\n");
実はコレ初心者には深い意味は理解できない。

2025/09/19(金) 18:20:32.71

くだらね

2025/09/19(金) 19:00:56.16

まぁ初心者はそう思うやろ

2025/09/19(金) 19:40:35.09

printf("Hello work.\n");

2025/09/19(金) 19:47:10.09

>>13
じゃあその深い意味を説明してみろよ
添削してやるから

2025/09/19(金) 20:28:54.31

>>11
下記に何かしら含意を感じましたが、意味は理解できませんでした。
・'H' が小文字でない。
・カンマで区切られていない。
・ピリオドで終端された。

**デフォルトの名無しさん** (ｽﾌｯ Sd5f-ilUi) · 2025/09/19(金) 20:38:58.85

\nは一文字だが環境によっては実際に印字される文字数が変わる話か

2025/09/19(金) 20:51:06.48

脈絡なしに突然上から目線で語り始めるのは老害じじいの特徴

2025/09/19(金) 21:15:49.58

>>16
全然違うんだよなあ

2025/09/19(金) 21:17:56.30

>>17
ああ確かにそれはある。
0d, 0aだったり0aだったりするな

2025/09/19(金) 21:20:05.58

>>18
分からないのか悔しいクズの他責思考

2025/09/19(金) 21:32:26.80

一般的な仕様
定義 #include <stdio.h>

int printf ( const char * format, ... );

※C99規格では以下の定義となる
int printf ( const char * restrict format, ... );

2025/09/20(土) 09:04:05.64

https://qiita.com/kaityo256/items/6ca69143901a02b32a85

2025/09/20(土) 11:05:51.36

printfの戻り値について、有効な使い方を教えて

2025/09/20(土) 13:40:53.82

プリンターのトラブルで印刷に失敗したらエラーを返す

2025/09/20(土) 14:28:17.33

そっかー
すでに終了してる書き込み先のプロセス(パイプで接続)に書き込んだときのシグナルって、なんだったかな

2025/09/20(土) 14:31:14.70

SIGPIPEか

2025/09/20(土) 16:58:37.16

特定の実装でたまたまそうだったからと言って
全ての実装でそうなっているかどうかは別の話
優しくしてね

2025/09/20(土) 17:25:51.73

霊界通信だな

2025/09/20(土) 17:26:59.16

ID:I8uDgIdj0 このprintfじじい何言おうとしたか忘れたな

2025/09/21(日) 04:07:46.37

内部通報で無理なので犯罪者通報

暗黒状態の量子もつれを生成することに成功：世界初の快挙
公開日2025.09.10 18:30:27 WEDNESDAY
https://nazology.kusuguru.co.jp/archives/184832
>>量子もつれが非常に壊れやすく、外界のノイズ（熱の揺らぎや周囲からの電磁波など）によって簡単に消えてしまうことです。
>>このノイズによる量子もつれの崩壊現象は「デコヒーレンス」と呼ばれ、量子技術が実験室の外で広く実用化されるのを妨げる最大の壁となってきました。
◇
・どうやって地上で行えるのですか？
・嵐の中や甘風が強い中での車での走行中などどうやって維持しているのかな
・UFOは重力県内でテレポートしている偽物だろう？
◇
・統合失調症から見て犯人不明で周囲の人は知っているかもしれませんが宇宙人だと名乗っているのとテレポート技術を所持している
・7人殺害した
・お前で埴鎮目だ
・殺害した人野事を晩酌で高笑いをしている
・お前「被害者＝統合失調症＝２４実感３６５日幻聴などの幻覚あり」を人質に立てこもる
・絶対に殺させる「自殺か殺人かは不明ですがさせる」
・コロな症状を引き起こせる
※など上記の事を話してきた
◇
ここにも愉快犯の犯人組織が居るだろう！

2025/09/23(火) 07:07:11.79

そもそもprintfなんて初心者しか見ないからなｗ

2025/09/23(火) 07:49:44.65

まじかよ20年以上使ってる俺は恥知らずかなんかなのか?
printfファミリーは標準ライブラリではぶっちぎりのイケメンだと思うんだが
何年か前に買ったマイスターシュテックって万年筆にも「snprintf」って名入れしたくらいだし
ちなみに標準ライブラリで次に好きなのはsize_t型とNULLマクロ

2025/09/23(火) 14:22:38.23

printfはスピートが遅いからなあ

2025/09/24(水) 12:40:37.19

組み込みでも無い限りらprintfで充分だろ

2025/09/24(水) 19:27:33.73

printfじゃないならなに使うの？

2025/09/24(水) 20:03:29.17

printf多用する場面ってそんな速度必要か？
テキスト表示のアクションゲームでも作るんか？

2025/09/24(水) 20:34:19.07

ちなgccならputsに置き換え可能なら勝手に置き換える

2025/09/26(金) 13:37:49.15

今時プアなマシン使っているので無い限り
実行速度難敵にする奴いないだろう

2025/09/26(金) 16:32:57.14

プアなマシンを使っているのでやっぱつれぇわ

2025/09/26(金) 17:25:52.87

かつてプアだった頃、他の奴が16ビットPC使っている中自分だけ8ビットPC（nec PC8001mk2）使って蔵書管理プログラム書き上げたな。漢字も扱えてたよ。出力はEPSONのMP80というカナ印字ドットインパクト、これの1/2ドット改行隠しコマンド見つけて16ドット漢字出力させてた。漢字ROMからのイメージ取得や展開にアセンブラも使用。実用性は殆どないが、勉強にはなった。

2025/09/26(金) 17:27:17.64

プログラム内にデータ組み込んじゃってて使えないやつだろｗ

2025/09/26(金) 18:19:46.34

今のprintfはコンパイル時にパラメータtypeチェックまでやってて
安心だけど気持ち悪さもあるｗ

2025/09/26(金) 19:32:39.45

printf(null);

2025/09/26(金) 19:46:41.37

$ gcc printf_null.c
printf_null.c: 関数 ‘main’ 内:
printf_null.c:4:10: エラー: ‘null’ が宣言されていません (この関数内での最初の使
用)
　　4 |　 printf(null);
　　　|　　　　　^~~~

2025/09/28(日) 12:37:58.28

printfに謝れ

**デフォルトの名無しさん** (ｽﾌｯ Sd43-LKjL) · 2025/09/30(火) 09:15:55.03

Mingw の mkdir には
mkdir(path, mode)
mkdir(path)
があるけど
Windowsにmodeが意味ないのはわかるけど
一緒にしといて欲しかった

2025/10/12(日) 01:15:00.07

>>47
mingw系はあまり知らぬのだが…それでも一般論として設計の筋が悪いことはわかる

mingw（or 今流行りはフォークの-64だっけ？）はlinux上でwinターゲット、あるいは（こっちも可能だけど少数派？）win上でlinuxターゲットのバイナリを吐くためのものなので、なおさらそうだろう

たとい無意味なmode引数であれ、プロトタイプを同一にするために受け付けるべきだろう
要らぬのならば捨てよ、互換性が何より優先されることだ
捨てて困るなら独自に解釈して適当なマップしなさい

最小例として
```
int my_mkdir(char const restrict * path, [[maybe_unused]] mode_t mode) {
return mkdir(mode); //mingwのmkdir
}
```
もしmode捨てて困り、アホほど暇なら、独自にmodeを解釈してntfsの同等物へ適切にマップしなさい

そしてその場合でも人が無用に混乱せぬように、その意図を以上のようなラッパでも書きなさい

2025/10/12(日) 06:33:04.28

そういやmsvcの_mkdirもconst char * pathの1引数だな

>>24
初めに文字数を数えた後(固定ならstrlenでもformat directiveで変わるならsnprintfとかでも)、printfの返り値との差をとり0にならないならば全て正しく書き込めてない
文字列を指すポインタを書き込めた数だけ増分した後に、先に得た差の分だけもう一度書き込む

2025/10/12(日) 06:48:57.50

もちろん2回以上も失敗しえるからループで回して返り値が0になるまで、あるいはretry回すこと
また負値が出たら当然exit()すること

私はstdarg.hを使って
int printf_ensure(const char restrict * fmt, size_t retry, ...);
のようなプロトタイプにしている
(retryが0ならば無限試行)

速度が問題でない場合、あるいは開発中は全部コレでprintfやputs差し替えたっていい
マクロでトークンprintfをprintf/printf_ensureで切り替えられるようにしておくとなおよい

2025/10/14(火) 00:04:27.04

Cのマクロでテンプレート（ジェネリクス）もどき。
C11以降で使える総称選択(_Generic)はジェネリクスというよりオーバーロード。

やっぱりCにもテンプレート欲しい。
（記憶が確かならC++のテンプレートは関数スコープ限定のマクロみたいな仕組みで、コンパイル時に型決定するのでパフォーマンスに影響しなかったはず）

#include<stdio.h>
#include<stdlib.h>
#define N 5
#define MT int
#define MV int
#define PT int
#define PF "%d,"

void mymap(MV (*)(MT), const MT*, const int, MV*);
void print(const PT*, const int);
MV inc(const MT);

関数の頭文字（または関数名）＋（T,V,U）な命名規則で#defineする。

2025/10/14(火) 01:00:24.48

c++の必要なとこだけ使えばいいだろ

2025/10/14(火) 07:01:23.65

やっぱそうなるよね。
まあ、組み込みとか必ずしもC++があるとは限らない環境でなんちゃってテンプレートの例みたいな感じで。

2025/10/14(火) 07:43:06.49

c++が使えないけど最新のcが使える環境ってのもレアじゃね？
大抵c89、運が良くてc99

2025/10/14(火) 09:00:12.91

Z80 がターゲットでもモダンな C コンパイラがあるよ。

2025/10/14(火) 09:51:45.01

マイコン用ならC健在だろ

2025/10/14(火) 12:31:26.84

そういう用途ならRust一択

2025/10/14(火) 17:14:48.06

>>54
一応、なんちゃってテンプレートはC89でも使える。

>>57
Rust処理系あるならそっちのが良いけど、まだCPU選ぶんだよね…。

2025/10/14(火) 17:59:04.47

演算子オーバーロードを使えるように拡張した C 処理系は知ってるけどテンプレートは見たことないなぁ……
色々な機能がお互いに関連するだろうし、テンプレートだけをポンと入れられるようなもんでもないと思う。

C を経由してコンパイルするタイプの言語 (処理系) でパラメトリック多相を使えるものを検討したらどうだろう。
nim あたりなら組み込みシステムにも使えるんじゃないか？知らんけど。

2025/10/15(水) 07:14:26.88

思えば、C++ない組み込みだったらそもそも浮動小数点数をが無いし、charは文字型と同時に1バイトの整数型だから最悪long型で作れば暗黙的型変換で行けるわ。
組み込みでC＋＋あるならテンプレート＋Cで速度も落とさず行ける。
(C++はCより2倍遅い)

とはいえ、仕事だとC++の既存資産を無視するわけにも行かんか。
理論上、密結合なOOPより疎結合な高階関数の方が再利用性高いとはいえ、一から作ったんじゃ開発速度が犠牲になる。
現実はかくも難しい…。

2025/10/15(水) 09:31:18.63

cコンパイラしかないようなマイコンなんてコードの規模小さいだろ
余計なことせずに愚直に書いとけ

2025/10/15(水) 15:50:44.46

いまどきのマイコンはpythonだって使えるだろうに

2025/10/15(水) 17:37:28.97

メモリー64kBでもいける？

2025/10/15(水) 18:42:39.89

何百円、あるいは何千円の石の話だよ
一個¥10の石ならまだまだcかアセンブラしか無理だろ

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

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