C言語なら俺に聞け 164

(新スレ立ての際上記コマンドを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

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

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

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

おー、ごめん

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

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

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

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

リアルタイム翻訳の「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で何ができるかを全て書いている

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

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


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

スレ立て乙です

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

くだらね

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

printf("Hello work.\n");

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SIGPIPEか

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

霊界通信だな

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

printf(null);

printfに謝れ

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

>>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の同等物へ適切にマップしなさい

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

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

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

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

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

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

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する。

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

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

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

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

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

そういう用途ならRust一択

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

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

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

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

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

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

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

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

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

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

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

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

我が家みたいだ

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

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

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

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

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

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

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

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

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

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

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

量産して売るのか？

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

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

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

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

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

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

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

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

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

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

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

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

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

それは多分、推奨が変わって、それに合わせて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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

>>105
同上。

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

>>107
今回の文脈は、

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

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

これだからＺは。


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

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

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

いくつから中年ですか？

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

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

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

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

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

>>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 コンパイラか何かがあるの?

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

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

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

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

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

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

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

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

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

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

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

それで正しいよ

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

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

>>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++だろうよ)

>>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++だろうよ)

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

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

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

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

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

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

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

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

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

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

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

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

ここでおそらく、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に癒着している。とはいえこれが問題になる事はまずないはずだが)

書けない？テスト

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

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

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

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

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

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

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

これにより、M側はsqliteと

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

アーカイブして戻すだけではなく、ライブファイルシステムとして使えるようになる。
これは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インタフェースも同じ、ということ。
そして繰り返すが、トークン分割の必要はない。もっと初歩的な、文字置換だけで済む。

つまり構成としては、
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しか説明出来てないが、面倒なのでこの辺で止める。
馬鹿に一々付き合ってても、ネットでは無限に馬鹿が沸くので、キリがない。
お前らが俺以上に手間を掛けたと分かる場合のみ相手するが、おそらくこれはないはず。
そしてこれ以上お前らが馬鹿こいても無視するのでよろしく。
無知のままで居るのもお前らの自由ではあるし、本当にキリがないので。

以上、終わり

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

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

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

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

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

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

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

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

typedef enum {} PINSTATE;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cで作るの？

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

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

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

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.

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

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

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

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

UTF16は廃止してほしい

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

>>175
無いです

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

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

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

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

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

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

long longでいいじゃん

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

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

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

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

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

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

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

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

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

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

gmp使ったソースだった

これだ
https://www.youtube.com/watch?v=prVBoU6K9Hg#t=6s
6秒-

>>1
JPCERT C コーディングスタンダード
に準拠しているか調べる無料で簡単なツールってない？
make/gcc の option でいける？

こういうのも、流行のclaudeとかで聞くもんなんかな？

ツールを起動するだけで CERT C コーディングスタンダードに準拠か否か判定するというレベルの簡単なものはないというか無理。
機械的な検証が困難な項目は人が精査する必要がある場合もあるからツールはあくまでも補助だよ。
まずは項目を大まかに分類して機械的に出来るところは機械的にやって残りは人が検証 (レビューやテスト) する体制を整えるしかない。
きちんとやろうとすると技術的なことより組織の運営の話になるんじゃないかな……

コーディングルールはサイトでの指定以外は気にしたことが無いなあ笑

C言語であるサブルーチンを作ろうとしてるんだけど、FILE* fで開いたファイルを一旦閉じて作業をして、また開きたいんだが、FILE* f だけを引数にしたい。そんなこと出来る？
開いたファイルの名前を引数にできれば、その名前で再度開けるが、FILE* f のポインタだけを引数にしてそんなこと出来るのかな？

できない
FILEが生きているうちならパス名を調べるのは多分できるだろな

>>198
閉じた時点で FILE* 型のハンドルは無効になる。
無効になったハンドルに対して出来ることは何ひとつない。

ファイルを開いている内に再び開くために必要な適用な情報を確保しておくしかない。
言語仕様上は細かい規定は無いのでホスト環境 (OS) に依存したなんらかの手段を使う必要がある。
Linux なら inode 番号あたりを保持しておけばファイル名を覚えておくより短くて済むからいいんじゃないかな？
まあ開くときにはたぶん一旦ファイル名を取得する必要はあるんだけど。
(他の OS でもだいたい似たような仕組みは有る。 Windows だと GetFileInformationByHandle を調べてみると良い。)

みなさんありがとう。OSはWindowsです
GetFileInformationByHandle も調べてみたけど、これではファイル名は出てきませんね
多分FILE* fからファイル名が出てこないと、無理っぽいですね

GetFinalPathNameByHandle
geminiに聞いただけで期待通り動くかは知らん

windows の場合はファイル番号 (FRN) から直接にファイルを開くことができるっぽい。

>>202
GetFinalPathNameByHandleやってみたけど残念
まあ、考えたらWindowsではHANDLE。FILEではないからね。HANDLEなら多分うまくいくんだろうね
でもいい関数を教えてもらいました。ありがとう
FILEからHANDLEに変更して作り直すかな。他人が作ったソフトを改造してやってるので
そもそも、FILEとHANDLEって何が違うのかなコンバートって出来る？
HANDLEはWindows専用でやってそうだから無理そうね

>>204
FILEからHANDLEは取り出せる
よく調べろ

Windows では FILE の下にファイルディスクリプタっぽいものがあって、その下に本来の Win32 API があるという三層構造になってる。
msvcrt.dll (または ucrt.dll) が C や POSIX の仕様に合わせた機能を提供しているが、必要に応じて Win32 API 用のハンドルを取り出すことはできる。

ありがとう。調べてみます

最近開いたファイル　から引っ張ってこれないのか？

>>198
階層設計間違ってるだけだと思うがな
https://atmarkit.itmedia.co.jp/bbs/phpBB/viewtopic.php?topic=33590&forum=7

そのファイルを誰かが開くことは想定しなくて良いのか？

>>198
それ絶対に閉じないといけないのか？ fflush() するだけじゃダメ？

DBとして機能するファイルならDBつかえよ？

あるやん
https://learn.microsoft.com/ja-jp/windows/win32/memory/obtaining-a-file-name-from-a-file-handle

https://learn.microsoft.com/ja-jp/cpp/c-runtime-library/reference/get-osfhandle
HANDLE h =(HANDLE)_get_osfhandle(fileno(fp));

質問者の意図がよく分からない
FILE*で操作したいと言うことは、
誰かが上位でopenしてくれる前提なのかな？

こうしてバグの温床が生まれたと。

他人が作ったプログラムをよく理解しないまま改造するという前提ではなるべく構造を変えないという選択肢がマシになることはなくもない。
もちろんきちんと理解して必要な形に整理しなおすのがよりよいに決まってるんだが、そう理想通りにできるとは限らない。

なんなの、この糞コテ？

おいしそうだろ

>>218
お前よりは数段役にたつやつだから 暖かく見守れ

うちの近所にも蜂蜜餃子出す店ある

ユーザーからの入力によって配列のサイズを決定したいんですが
どうやったらいいんでしょう

>>222
質問が分かりにくいのでどう書きたいのかコードで示して欲しい。
意図がわかればよいのでコンパイルエラーになるようなコードでもかまわない。

たぶん必要なのは malloc だと思う。

その他、配列の型としての大きさを実行時に変えられる場合は限定的だが VLA と呼ばれる言語機能がある。
ただ VLA は後の仕様改訂でオプショナルになったので使えない処理系もたぶんあるしエラーハンドリングに難があるので避けたほうがよいと思う。

>>222
comp.lang.cのFAQは読んだんか? 配列についての昔々からあるお前がしたような質問と回答がそこに載ってんぞ
せっかく親切に>>1がリンクまで貼ってんだから>>1くらい読んでから質問しろよ お前どこ行ってもそんな風な振る舞いなのか?

argcをどうやってatoiしたらよいか、なんて話題かもしれない

>>222
ユーザーが入力し得る最大サイズで確保しとけばええねん

ふつうテラバイトかな

>>222
とりあえず入門書を読み直せ

> Z世代「結局、俺等って最も賢くて不幸な世代じゃね？」2万いいね [237216734]
> https://hayabusa9.5ch.net/test/read.cgi/c/news/1768856467/
典型的Zムーブやん、もうちょっと生暖かい目で見るゆとりを持とうぜ

>>228
意味のないレスだよ

やや曖昧だったので補足しておくが、俺は>>228も正しいと思っているし、批判する気もない。
ついでに一言ずつ感想を述べると、

222: Z過ぎる…
223: "malloc"というキーワードすら知らなかったのだから、そんな高尚な話ではないのでは…
224: あー、昔はnewsで同様のことをやってたんだな、知らんかったわ。まあ読んだほうがいいね
225: エスパー能力は低そうだな
226: それもありよね、というか俺ならこれかな
227: アホだな
228: まあこれもそう。書いてあるだろうし、224のFAQにしても知らないことも多いだろうから、全部読むのが一番効率はいい(ただZは絶対に受け入れないが)
(229: 俺)
230: お前がもっとも意味ないよ、死ね

ちゃんと目が覚めてからどうぞ

苦しんで覚えろC言語

NNTPってまだ使われてんの

シーは可変長配列実装する所からか

C調実装に御用心

たまにゃMakefile

>>231
226は一番ダメだろｗ
素人はいくらでも想像できない限界を超えてくるし
長大なデータを入力し終わってクラッシュした時の脱力感はやった人間ならわかるはずｗ

翌日には忘れる未来志向

>>238
中級レベルには意外だろうけど組み込みでは常套手段
ワーストケースを決めてリソースは固定で確保
実用的な上限設定すればいいだけ

Dィープsテートは人類の電子的支配をねらっている
https://www.youtube.com/watch?v=-HUCdYNePFg

クラッシュして良いわけではないが想定した固定長を越えたらエラーメッセージを出して直ちに終了するくらいの方針はありうる。
Worse is Better ってやつだ。

中級者
超えないようにメモリを冗長化

上級者
デカいメモリを確保ANDユーザの入力次第でクラッシュ scanf指向

全部固定長にしちまえばいいんだよ

sprintf, swprintf, _sprintf_l, _swprintf_l, __swprintf_l,
sprintf_s, _sprintf_s_l, _swprintf_s, _swprintf_s_l,
sscanf, _sscanf_l, swscanf, _swscanf_l,
sscanf_s, _sscanf_s_l, swscanf_s, _swscanf_s_l,
さらに
vfprintf, _vfprintf_l, vfwprintf, _vfwprintf_l,
vfprintf_s, _vfprintf_s_l, vfwprintf_s, _vfwprintf_s_l,
なんで vwfprintf じゃねえんだよ！って思う

強い相互作用が働いています

printf("%d\t%d", fahr, celsius);

の引数である、"%d\t%d"について質問です。

「\t」はタブ文字を表すということです。
viなどのエディタではタブを入力すると4文字や8文字などの設定した幅だけ空白が挿入されます。

"%d\t%d"についても同じように4文字や8文字などの一定の幅の空白が整数と整数の間に挿入されるのかと思いましたが、動作が違うようです。

これはどういうことでしょうか？

> viなどのエディタではタブを入力すると4文字や8文字などの設定した幅だけ空白が挿入されます。

こういうのはエディタがキー入力されたタブ文字をタブ文字として出力せず、4文字、8文字の空白として出力（つまり変換）してる

> "%d\t%d"についても同じように4文字や8文字などの一定の幅の空白が整数と整数の間に挿入されるのかと思いましたが、動作が違うようです。
コンソールなどにそういう機能がない以上はタブ文字はタブ文字として出力されるだけ
もしタブを入力として受け取って、それを4文字や8文字などの空白にしたいなら自前でそういう処理を書かないといけない

>>247
・タブという文字 (一文字) がある
・タブ文字の幅は一定ではない
・タブ文字は次のキリの良い桁までの幅を持つ
・キリの良い桁がいくつであるかはターミナルやエディタの設定によるが一般的に4か8
・つまりキリの良い桁が4に設定されている環境において、行の最初にあるタブの幅は4だし、三文字目にあれば幅は2になる
・設定によってインデントの大きさを一気に変えられて便利なのでかつてはタブでインデントするのが普通だった
・現代ではフォーマッタが総合的に面倒を見るのでインデントのためにタブを使う習慣は廃れた
・タブキーを押してもタブが入力されず空白を入れるようになっているエディタはそこそこある (設定で変えられることもある)

そなたらはC99以降を使ってんのかどうしてんだ。
後からC++で使う可能性があるなら互換性を失ったCを使うかどうかは考えないといけない。
拡張子.cと.cppを共存できるプロジェクトファイルに対応の機械語ファイル作成のソフトとかあるんかな。
例えばVisual C++はどうなんや。

>>250
主要なホスト環境 (OS) や処理系はかなり保守的な体制をとっていて MSVC, GCC, Clang といった主要な処理系は C89 をいまだに使えるし、 ABI に互換性がある範囲で C++ と共存できる。

特に MSVC (Visual C++) の C は「ANSI C89 にマイクロソフトに独自の拡張を付け加えたものである (その独自拡張が C99 の一部なこともある)」 と説明しているくらいの保守的姿勢をとってる。
その割に安全でない関数を使ったときなどの警告は厳しめなので寛容だがモダンなスタイルへの移行へ積極的でもあるという感じに見える。

書き方がまずかったか。
機械語ファイル作成のソフトの具体例は、Microsoft Visual Studio(Visual C++)で、プロジェクトファイルの具体例はVisual Studioでは拡張子.vcxprojのファイルのことを言ってる。
互換性で問題にしてるのはC99以降で、C++98に対応のコンパイラなら、C90までのCで互換性の問題は普通に考えてあるとは思えない。
shortにintを代入で警告、ポインタ変数にキャスト無しでvoidポインタの代入でエラーくらいしか思いつかない。

>>252
確認だが >>250 で言う「後から C++ で使う可能性がある」というのは「C++ とリンクする可能性がある」ではなく「C++ としてコンパイルしなおす可能性がある」という意味だったの？
「それだと .c と .cpp を共存できる」に繋がらなくて意味を読み取れないんやが。

そうか、リンクという方法もあるわな。
でも言おうとしたのはC++としてソースを再利用してコンパイルのつもりで言った。

ただし、.cを単に.cppに変更してC++プログラムとして使うと互換性を失うので、１プロジェクトの中にCとC++を共存させてハイブリッドのコンパイルはできないものかと思ったわけだ。

>>255
C と C++ をひとつのプロジェクトの中で共存させることはごく普通にできる。
あまりに当然のことすぎてそこが疑問なのだとは気づかなかったよ……
私自信は Visual C++ を使ってないから具体的な操作までは知らんけど。

そうだったか。
それなら最新のCを使うのもいいな。

もともと C と C++ はつかず離れずを指向していたんだけど C が保守的すぎて乖離が大きくなっていったという事情がある。
C23 でその間を埋めるように大きめかつ非互換な改定が入って GCC ではすでに C23 がデフォルト (オプション指定しなければ C23 になる) なんだけど MSVC で使うのは時期尚早かもしれない。
処理系のデフォルトがおおよそ無難な選択だと思う。

そなたらはC99〜最新はどういう立ち位置でいる？
1.拒絶派
2.慎重派
3.条件によって二分する中立派
4.積極派
5.最新仕様を最大活用派

しょうもないキャラ作りすんな
答える気なくすわ

>>259
先述の繰り返しになるが処理系のデフォルトが無難と考えている。
開発のインフラを作っている人たちの判断を信頼する。
GCC が C23 で Clang が C17 だからそのくらいが現在の相場だってことだ。
その上で特にプロジェクトの事情があるなら配慮する。
結果的に新しい機能を使わずに済んで C99 としてもコンパイル可能であるようなものを書くことはあるかもしれないけど C99 の機能を使わないということは無いので C89 は論外になるな。

あなたもわたしもCCG

それはCGC

>>255
.c と .c++ を共存させたいときに
.c を .cpp に名前変えるのはあまりにも筋が悪いと思う
>>253 や >>256 さんの言う様に
.c と .c++ を普通に混在したままリンクする方が良い

よっぽど頭にきちゃったんだね

一緒に仕事したくないな

Turbo C使いの俺には死角はなかった

懐かしい世界

明日は晴れるかな
https://ideone.com/TW6fsG

ポカポカな天気

書き込みテスト

ioになったんか

sys/io.h のこと?

https://gigazine.net/news/20260311-tony-hoare-passed-away/
ホーア先生亡くなってしまったね．

「ソフトウェアを設計するには、2通りの方法がある。1つは、とてもシンプルに設計して、明らかに欠陥がないようにすること。もう1つは、とても複雑に設計して明らかな欠陥がないようにすることだ」

誰か説明して。前半はなんとなく分かるが。

説明も何もそのままじゃん

オラは凡人なので、複雑な設計と無欠陥を両立できません笑

「明らかじゃない欠陥」が噴出するのさ

明らかな欠陥がないようにする，って書いてあるじゃん．

>>280
俺に言ってるんだったら論理的思考力がプログラマレベルに達していないぞ

潜在的な欠陥とか無い様に全ての条件で確認すんだよ

> 明らかに欠陥がないようにする
部屋には一切物を置かず、ごきぶりが居ないことは見れば分かる

> 明らかな欠陥がないようにする
部屋を複雑に設計しゴキブリが侵入する余地を与えない
出入りする者、物においてもしっかりとしたチェックを行いゴキブリを連れ込まない

複雑なロジック設計して、
他の人には一体何をするためなのか
意味不明なプログラムなら
書いたことはある笑

>>276
複雑なものを作るのに欠陥が無いようになんて出来ないことはわかるだろ。
だから残る選択肢はシンプルに作ることしかないんだ。
いわゆる反語、皮肉めいた言い方で茶化してるだけ。

おいおい大丈夫かよこのコテハン
ホーアを知らないで言ってんのか？
そーいうことじゃないよw

https://dic.nicovideo.jp/t/a/%E3%81%BB%E3%81%A3%E3%81%A1%E3%82%83%E3%83%BC%E3%82%93%21%20%E3%81%BB%E3%80%81%E3%81%BB%E3%83%BC%E3%81%A3%E3%80%81%E3%83%9B%E3%82%A2%E3%82%A2%E3%83%BC%E3%83%83%21%21%20%E3%83%9B%E3%82%A2%E3%83%BC%E3%83%83%21%21

ガチもんの人かヤバw

>>276
その書き方でもまあ分かるけど原文読んだ方がいいよ
明らか「に」欠点がないのと明らか「な」欠点がないは違う
包有関係考えれば分かるけど噛み砕いて言えば難しいバグがあるってこと
シンプルに作れば正しいかどうかは目で見て分かるが、複雑だとそれが出来ず正しいかどうか確かめたかったら例えば数学的に正しさを証明しないといけなくなったりする
複雑さは品質の証明にならないってこと、単純な設計をする困難さなんかを言ってる
もうちょい短くすれば要は複雑さは設計の失敗のサインだって意味の文章だよ

IQは日本語読解力に比例するらしいが正しいと思える瞬間な

日本語読解力の問題なら、
プログラムの話題ではないな

>>290
ハーフリンガル問題の事だと思うが、勿論鶏と卵の関係であるにせよ、主たる因果関係は逆で、
IQ→国語力
だと思うがな。国語力→IQなら、文系馬鹿が最高に賢くなってしまうし。
だからって、最近のセンター試験の数学が国語化してるのは、関係各者の妥協の産物ではあるにせよ、間違いだと思うが。

>>291
プログラミングと言うよりは、エンジニアリング全般の話よね。
いわゆる「一方、ロシアは鉛筆を使った」でもあるし。

C言語の話題でもないし、
これ以上続けるなら
プログラム設計のスレがふさわしいよ

>>293
賛成だがそういう場合はリンクを貼るべき
少なくともム板マ板のどちらにもない

このコテハンの人、規格の引用みたいな誰でもできる機械的なことやってるうちはいいけど
ちょっと自分の意見言い出すととたんにトンチンカンっつーかズレたこと言い始めるよねw

>>292訂正
✕ ハーフリンガル
○ セミリンガル

>>295
今回はお前の方が頓珍漢。

> 規格の引用みたいな誰でもできる機械的なこと
誰でも出来るわけではない。かなり詳しいのは確か。
文句があるならお前も参戦してどちらがより正確かを競うべき。(＝ネットは衆人環視なのだから、衆人に役立つ方向に競え)
ゆとりZはすぐに人格ガーの方向に持っていくから、（＝衆人にとってまるで役に立たないマウント取りに勤しむので)
SNS上で役に立つ議論が出来ず、彼ら世代だけでまともな議論場を確保できない。
だから老人ホームな5chに来ざるを得なくなってるのを反省し、行動を改めるべき。
ゆとりZだけの場所で5chと同じことが出来たら、彼らにとっても幸せだと思うんだけどね。
(ただし根っこはゆとりZの「自分のお気持ち>>>技術論《正しいかどうか》」な価値観だから本質的にかなり無理だが)

して、289が正しいと仮定して、それを276と二言で表現した場合、
それを285のように説明するのは間違いでもなく、不適切でもない。
276だけだと、「複雑な設計では明らかではない欠陥はあってもいいのか？」が曖昧でツッコミたくなるが、
289と276のこの点への解釈は揃ってるし。
というかこの辺で手こずるようなら、プログラミング以前に国語をやり直すべき。

AI時代は国語力とか言うポストがバズったりしてるけど国語力って幅広すぎだよな
効率的なトークン生成スキルといったほうがいい

論理的思考ができるかどうか、プログラムでなく文章を書かせてみる、ようなことはよく言われるね

IT土方なら文章でわかるかもな

292や296も変な文章に見えるけどなんかもうキリがないなw
誰か指摘してあげなよ

>>300
ゆとりZキチガイは5ch止めろ。

というかね、ゆとりZ的精神的勝利法なんて何度目だ？過ぎて。
こいつら本当に進歩せず、幼稚なままだ。
日本語が出来ないお前には読めないのだろうが、
俺の文章は普通の知能な日本人には確実に通じるレベルだし、多分お前よりもだいぶましでもある。

自分で詳細に論理的説明も出来ず、また日本語が拙い事がバレるので、自分では指摘出来ないんだろ。
出来るつもりなら書けばいいだけ。お前が書かないとお前が書ける事の証明にはならない。
そしてその書いた内容が妥当なら、お前に同調する連中も現れ、お前の望む方向に流れるだろうさ。
これが本来の自由な議論場の有り様。5chはずっとこうしてきた。
何も言えない奴に存在価値は無い。

本当に、ゆとりZは死ぬべきだよ。
5chもゆとりZが居なければ、もっといい場所になるのに。
(つってもこの文章も国語力無いゆとりZ連中には通じないのは分かってるが…)

まあ俺はこの手のメタ話は割と好きなので参戦してるが、
ついでにかねがねコミュ障だと感じてるお前らに対し、俺的流れの理解を説明しておくと、

ゆとりZ276: これ教えて
その他大勢: いやまんま過ぎて何が分からないのか分からん
(超絶豆腐メンタルなゆとりZにとっては285は十分に暴言であり攻撃だと受け止められた！！！)
ゆとりZ295: ムキー！！！285はぼくをこうげきしてきた！！！はんげきしてやる！！！トンチンカン！！！
俺296: いやお前の方が頓珍漢
ゆとりZ: 285をようごする296もきにいらない！！！こうげきしてやる！！！296もにほんごがおかしい！！！
(元々日本語の問題だと言われたので、
自分の日本語がおかしいのではなく、他人の日本語がおかしいとの他責思考により、
攻撃箇所が295での人格→300での日本語にシフトした)

まあよくある馬鹿狂犬ゆとりZだ。
一向に論理的フェーズに突入しない。多分今後ともそうだろう。
そもそも言葉とはコミュニケーションの「手段」であり、「目的」ではないので、
通じてるかどうかが最大に重要であって、正しい言葉を、或いは上手い下手も、通じる確率を上げる方策でしかない。
(逆に言えば、通じてれば何でもいい。相手の方言にも、また、誤用にも、場合によっては合わせてもいい)
それで、「目的」の、通じた後に何を得るつもりなのか？が、無いのもこの馬鹿狂犬タイプの特徴。
噛みつく事が目的化してる。いやそうじゃねえだろと。

ゆとリンガル問題、とでも命名しようか。

日本語が出来ず、論理的思考力もない、ゆとりZによって引き起こされる問題。(なおゆとりZの大半が該当する)
拗らせた承認欲求と他責思考により、ハイセンシティブピープーとなっており、過度に過敏で、やたらと攻撃されたと見なし、
反撃する事が目的化して、意味もない方向にどんどん流れていく。
仮に285の人格や俺の日本語に問題があったとしても、それが、当初の
> もう1つは、とても複雑に設計して明らかな欠陥がないようにすることだ
を理解する事には繋がりようがなく、掘り下げる意味がない。
この手の、「反論してきた人や内容に、微々であれ問題が存在したら、これまでの反論は全部無意味！！！」的な、
論点をどんどんすり替えていって、その途中でなんとか瑕疵を見いだし、俺負けてない！！！と強弁するのは、
典型的な詭弁論法で、名前も付いてたはず(忘れたけど)。ただまあ、ひろゆきがよくやってるのがこれだが。

議論は、常に原点を念頭に置き、目的を達成する事を目指すべき。
再度言うが、仮に285や俺に多大な問題があったとしても、元の疑問の解決には繋がらないだろ。
そもそも276で、

276: 後半部分が分かりません。○○と字面からは読めますが、私は□□だと思うので、矛盾します。私は私が間違ってるとも思えません(ｷﾘｯ

とでも言えば、ゆとりZ的にも気に入らない流れにはならなかったはず。
この辺も、他責思考で、何でもかんでも他人のせいにしてるから上達しない。
いやお前だけの努力でも完全回避出来たよねと。

ただまあ、このタイプが過半数だから、ゆとりZな場所ではどうやってもまともな議論なんて出来る訳無いのは分かる。
しかし5chでゆとりZ全開は邪魔でしかないので、俺は撲滅するべきだと思ってる。
(だからこうして賛同者を募るべく一々書いてる)

さらについでに言っておくと、
「明らか『に』」「明らか『な』」の違いが読めない国語の問題だと捉えた大半の人に対し、
285だけは、日本語の問題はクリアしてて、その後の矛盾に見える点について回答をしてる。
つまり、285だけは質問者276のレベルが一つ上だと認識して回答してるわけで、
承認欲求拗らせて「ばかにするな！！！」と噛みつくにしても、相手を間違えてる。
自分を一番高く評価してくれた人に噛みついてどうするよ？逆だろと。
回答の口調がゆとりZ的には気に入らなかったのだろうけどもね。
この辺が、ゆとりZがまるで表面的な所しか見えておらず、コミュ障な所だね。

>>298
それも逆(十分条件)だからフィルタにしかならん(でもやらないよりましだが)
論理的思考が出来ない→論理的文章を書ける訳がない
論理的思考は出来るが論理的文章を書けない＝ただのコミュ障　276も多分こっち

本来は論理能力は数学/物理で鍛えられるので、
昔の「最低限理系にプログラミングさせる」方針は概ね間違っていなかったが、
受験産業の結果、記憶力『だけ』で突破する受験特化型馬鹿が結構増えたのと、
そもそもプログラミング自体に数学/物理そのものは必要ないので、
「理系→プログラミング適正あり」のフィルタは迷走気味
とはいえ、「論理的文章を書ける→プログラミング適正あり」フィルタは、さらに酷いと思うけど

すげー、このスレで一番論理的思考ができる人じゃん

3行でまとめろ

昔は1行で書いてたな
プログラムの話だが

>>307
俺ら世代での「BrokenEnglish」問題が、ゆとりZでは「Broken日本語」問題になった
で、俺は同様に、Brokenでもしゃべった方がマシ、と言ってる
そして、よりによって、一番高く評価してくれた人に噛み付くのは馬鹿すぎ

と、ふと思ったが、もしかしてお前ら、
上記の一行目だけで全てが瓦解し、一瞬で、長文内容と同程度の詳細度で理解可能だったか？
だとすると、俺がお前らを過小評価し過ぎてた事になる
もしお前らの大半が「一行目だけ」で付いてこれるなら、この議論速度で突っ走ってみても良い
(勿論この場合は、通じない馬鹿は全員放置で追加説明もしない)

ちな、>>305訂正
× 十分条件
○ 必要条件
受験は大昔過ぎて素で間違えたわ
まあ、都合よく補完すれば読める範囲ではあるが

地下室の手記

292は比例の話をなぜか因果関係の話にしてんのがおかしいね
AがBに比例してるってことから言えるのはBもAに比例してるってことだけで因果関係がどうたらとか何も関係ない
数学的にはY=kXの時にX=(1/k)Yだから逆が言えるのはkが0じゃない時だけとかあんだろうがまあここでは関係ないわな
1行目からおかしいからその後も妙なことを長々言い続けるはめになってる

296はなんで「今回は」なんて付けたんだろうなw
そんなものつけなくてもいいどころか、後段を見れば付けない方がいいのにこういうのがついてしまう
なんのかんの言ってもコテハンの事を普段どう思ってたのかがつい出ちゃってるのか、それとも自分の思ってることを言語化する能力が低いのか
どっちにしても奇妙な文章だよ

シフトJIS混じりの文字列を扱うには、charと unsigned charのどちらが良いですか?

UTF16に固定しちまえ

>>314
signedの方が良いことって何かあるかね?

>>312
正解w

念のために補足しておくと、 char は signed char とは違う型として区別される。

unsignedだと比較がしやすいことはないですか?

charの符号の有無は未定義?のようですね

>>320
処理系定義ってやつ。
未規定の一種だが、処理系定義は処理系で決めてそれをドキュメントに書いておくことが求められる。

Shift_JIS を含む文字列を使うにはたぶん unsigned char が好ましいことが多いと思う。
ただ、有効型に関するルールとして整数型をそれの符号付・符号無としてアクセスするのは許されるという特別扱いがある。
(読み替えは型変換とは異なるので注意。)
つまり必要に応じて同じ文字配列に対して char[] としてアクセスしても unsgined char[] としてアクセスしても構わないので必ずしも最初から決める必要はない。
一貫したほうが分かり易いとは思うんだけど strcpy とかの文字列系の基本的な関数は char で扱ってたりするから……

>>322
>有効型に関するルールとして整数型をそれの符号付・符号無としてアクセスするのは許されるという特別扱いがある。
>(読み替えは型変換とは異なるので注意。)
規格の何処?

>>323
C99 なら 6.5

> An object shall have its stored value accessed only by an lvalue expression that has one of the following types:
> (オブジェクトに格納された値に対するアクセスは，次のうちのいずれか一つの型をもつ左辺値によらなければならない)
> --------------------(中略)--------------------
> — type that is the signed or unsigned type corresponding to the effective type of the object
> (− オブジェクトの有効型に対応する符号付き型又は符号無し型)

※ 括弧内の日本語は JIS から対応箇所を抜粋

>>324
丁寧に ありがとう

算術的に扱わないなら符号はないほうがよいというのが僕の考えで
今回はじめて知ったことですが、charの符号の有無は処理系定義というところが話を曖昧にしてるのですかね
算術的に扱わない場合の文字に符号があることにも違和感があるし、wchar_tもunsigned shortだったので、unsigned charでいくことにします

wchar_tを使っているわけではないです
文字を符号なしと扱うことを参考にするという意味です

>strcpy とかの文字列系の基本的な関数は char で扱ってたりする
符号の有無が原因だったかどうか記憶が曖昧だけど
警告が出まくってうざいときがある気がする

実行基本文字集合の要素は char に格納したときに非負で扱えることを言語の規格として保証してるから扱う文字がその範囲内なら char が符号付きかどうかに関係なく負数は出てこない。
逆に言えば負数になったら面倒くさいことがわかってるからこういう規格になってるんだと思う。

ただしASCIIに限る

C の規格の上では「実行基本文字集合」として文字を提示しているがその文字集合がどのような文字コードで表現されるかは既定しない。
ASCII (またはそれと互換？) は保証されない。

もしもたとえば EBCDIC を採用しているような環境なら char は必然的に符号無しになるね。

>>326
マヌケ

符号なしの罠を知ってるかはcの実力を測る試金石ではあるよな

マ抜いてみたが1字しか変わらん。
$ diff 326.txt <(sed 's/ま//g' 326.txt)
7c7
< 算術的に扱わない場合の文字に符号があることにも違和感があるし、wchar_tもunsigned shortだったので、unsigned charでいくことにします
---
> 算術的に扱わない場合の文字に符号があることにも違和感があるし、wchar_tもunsigned shortだったので、unsigned charでいくことにしす

文字種で集計するときに、算術的な処理できて便利です。

>>90
そりゃ、算術的に扱う場合も、ロジカルに扱う場合もあるでしょう

壮大にアンカミスったけど、直前のレスに対してでした

>>335 も僕に対する煽りではないかもね
失礼しました、ごめんなさい

基本的に文字列を扱うならcharを使え

tell me why

輝美 (てるみ) にテルミー

そこは照美

標準ライブラリが引数をchar *で受けるのも規格のcharの扱いに曖昧さがあるのも同じ理由に因ってる
特に規格の方はこうすることでコンパイラの作者とユーザーの双方に利が出るよう意図的にこうしてる
わざとはっきりさせないようにするのはCの規格によくある「味を残してる部分」なんだから、お前は何も考えずcharを使え

char が符号付きかどうかが処理系定義なのはアーキテクチャの都合に合わせられるようにするためだ。
(規格制定時にすでにどちらの処理系も存在したので追認したという消極的な理由もある。)
この場合はアーキテクチャに都合が悪いからといってやるべきことが変わるわけではないのだから曖昧なほうが良いなどという論に説得力は感じないな。

C11 で u8 プレフィクスを付けたとき (文字列を UTF-8 とするとき) に char で扱うルールにしたのは失敗だったと認めて C23 から char8_t 型を導入することになった経緯もある。
互換性を大事にする C で非互換な変更をするくらいには文字が負数になるのはろくでもないミスの元だとはっきりしてる。

strcmpの実装をみると、引数はconst char *で比較はconst char *でとするのが大概ですね

大概というか、いくつかみた中では漏れなく

>>345
比較はconst unsigned char *で、の間違いでした^_^;

Cで文字列操作なんかバグの温床になるだけだから開発言語変えるか仕様変えろw

おすすめの言語は何ですか？

Rust

>>347
それはそう。
比較関数では各文字は unsigned char として比較すると規格上明記されている。

規格書まで紐解かないとではなぁ…
MSのページだと、strcmpとマルチバイト用の_mbscmpが併記してあって、後者の引数は const unsigned char * なのも紛らわしい
後者はMS拡張だからそうできるのだろうけど

_mbscmpのシグニチャは最初の問いの答えだな…

文字列リテラルを char の配列であることにした以上は標準の関数の型をそれと合わせるという判断は自然なものだと思うよ。
全体として見ると変な感じだけど個々に見ると妥当な (少なくとも仕方ない) ように見える。

K&Rを引っ張り出して読んでみたけど、たしかにcharの符号の有無は機種によるとあり、比較の関数では、引数はunsigned char *の配列として扱われる、とありますね
一度は目を通したはずですが、すっかり忘れていました
というか、初学者のころにはその意味がよく理解できていなかったのだと思います

C23attributeの話このスレで見たことないんだけどみんな使ってます？

文字を扱うならcharを使うべき
signed charだのunsigned charだのは1バイトの整数型と思った方がいい

7ビットでおさまる文字は良いけれど
上位ビット立っている文字種は困らない？

お前時間止まりすぎだろ
そんな語り尽くされた話を今気づいたかのように話を始めるのやめろ

>>357
文脈を読んで。
整数やビットパターンとして扱いたいときの話をしてる。
文字の表現方法に踏み込まない不透明なオブジェクトとして扱える場合なら char でいいよ。

K&Rの段階でcharはunsigned型と決めてやればよかったのに

俺に言われても

アセンブラのラッパーだから型がいいかげんなのは仕方ないんだよ

charは8bit型ってことだったんじゃね