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/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使ったソースだった

2025/12/03(水) 11:46:07.94

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

2025/12/03(水) 22:47:42.54

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

2025/12/03(水) 22:51:48.92

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

2025/12/09(火) 18:21:11.05

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

2025/12/11(木) 01:14:00.20

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

2025/12/16(火) 15:40:55.95

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

2025/12/16(火) 16:02:20.55

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

2025/12/16(火) 16:25:43.79

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

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

2025/12/16(火) 17:12:42.21

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

2025/12/16(火) 17:27:33.70

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

2025/12/16(火) 17:47:00.48

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

2025/12/16(火) 17:48:08.13

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

2025/12/16(火) 18:25:26.73

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

2025/12/16(火) 19:25:00.08

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

2025/12/16(火) 19:50:18.68

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

2025/12/16(火) 21:05:39.33

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

2025/12/16(火) 21:38:52.25

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

2025/12/17(水) 00:35:55.40

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

2025/12/18(木) 01:16:26.13

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

2025/12/18(木) 09:00:10.06

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

2025/12/19(金) 13:27:44.03

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

2025/12/19(金) 13:33:27.31

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

2025/12/19(金) 14:08:20.19

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

2025/12/19(金) 17:52:53.90

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

2025/12/19(金) 20:20:49.60

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

2025/12/19(金) 20:28:04.21

なんなの、この糞コテ？

2025/12/19(金) 22:01:36.42

おいしそうだろ

2025/12/20(土) 07:50:33.87

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