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

以上、終わり

>>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ポインタの代入でエラーくらいしか思いつかない。