C言語なら俺に聞け 157

2021/06/28(月) 11:22:51.50

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

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.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言語なら俺に聞け 156
https://mevius.5ch.net/test/read.cgi/tech/1601271690/

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

2021/07/27(火) 19:55:06.48

>>114
同意だが、.で共用出来なかったんかね？
関数と関数ポインタみたいな感じで、左辺がポインタだったら逆参照してからメンバアクセス。

2021/07/27(火) 23:09:50.37

>>115
Rust ではそうしてるんだから C でも最初からそういう選択も出来たはずではあると思う。
だけど違うことをするのに同じ見た目にするのが良いかどうかというのは微妙なところ。
どちらが良いと一概に言えるもんではないからな。

2021/07/28(水) 00:16:37.31

CはRustの派生だったのか、知らなかった

2021/07/28(水) 00:34:49.35

>>117
派生関係も時系列も前提にしてない。
別の選択をしたものが事実として存在するので可能であるのは疑いないと言ってる。

2021/07/28(水) 00:53:01.29

FortranやCobolにも導入して欲しいのか？

2021/07/28(水) 01:00:09.40

うーん？

ある構文（範疇としては演算子の形態論？）について，
「他の言語での採用例があるからC言語がそういう構文を持っていても不思議じゃなかった」
という話が展開されていたと思うんですけど，
どうして「RustはCの派生」とかFortranやCOBOLの構文の話になったんですかね……？

2021/07/28(水) 01:46:29.97

バカだから

**デフォルトの名無しさん** (JP 0Heb-qCnf) · 2021/07/28(水) 09:52:29.36

C99以降で真偽型をboolのように表記したいときは<stdbool.h>を読み込みますが，
規格票には「型boolはマクロとして定義しろ」とあります。
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#section.7.18

一般に既存の型から新しい表記の型を定義するときはtypedefを使うべきだと
（典拠は失念したのですが）聞いたことがあります。
たしか，コンパイラによる検査があったりより構文的に厳密になったりするから，
というような理由だったはずです。
真偽型boolがtypedefではなくマクロで定義されている理由ってなんでしょうか。

思い当たる理由としては，C++との互換性がありますが，それをC言語の規格で考慮する意味がない
（というか，C++の規格をC側から参照すると循環的になってしまう気がする）
気がします…。
C規格の論理的根拠の真偽型にかんする節も読みましたが，
「typedefではなくマクロを使う理由」は記載されていませんでした。
http://www.open-std.org/JTC1/SC22/WG14/www/docs/C99RationaleV5.10.pdf

2021/07/28(水) 10:26:19.41

マクロだと#undefできるから自分でboolを定義してる古いコードのための移行措置っぽいね
<stdbool.h>をincludeしなければいいと思うけど間接的にincludeされるケースもあるんだろう
_Boolの方は予約語になってる

7.18 (4)
..., a program may undefine and perhaps then redefine the macros bool, true, and false.
プログラムはbool、true、falseマクロをundefineして再定義することができる

7.31.11 (1)
The ability to undefine and perhaps then redefine the macros bool, true, and false is an obsolescent
feature.
⇒　bool、true、falseをundefineして再定義できる特性は廃止されつつある

2021/07/28(水) 12:14:26.76

Win32APIとか使わずに
Cの標準関数でカレントディレクトリではなく
今実行中のexeのpathを得る方法はどれですか？

2021/07/28(水) 12:21:24.51

int main(int argc, char* argv[])
の　argv[0] で実行ファイルへのフルパスがえられるのは環境依存だったかな･･･

2021/07/28(水) 12:22:28.68

mainの第2引数の argv[0] にはコマンドラインから入力した通りのコマンド名が入っているんだっけ
フルパスで入っているんだっけ

2021/07/28(水) 12:24:05.30

被った
たしか Windows はフルパスだったような…
違ってたらごめんなさい

2021/07/28(水) 12:27:22.89

実装に依存

2021/07/28(水) 12:35:40.50

Windows という書き方はよくないかな
シェルの実装によると思います
なので、WSLに持っていくと期待通りに動かなかったりするかもしれません
ここでは Windows限定でよさそうだけど

2021/07/28(水) 13:20:46.92

え？そう？ Windows で C 使う人って今はあまりいないのでは? Linux とかなら分かるけど。

2021/07/28(水) 13:41:10.64

powershellはフルパスだけどｃｍｄは入力のまま
結局はCreateProcessに渡した文字列なのでフルパス前提にしちゃだめよ

OSに依存しない方法で確実なのはないよなぁ
argv[0]が
ファイル名のみ：カレント＋環境変数pathを走査
相対パス：カレントと連結
絶対パス：そのまま
とかやればそこそこいけるだろうけどめんどくさいな

2021/07/28(水) 13:54:41.98

純粋なC標準の範囲では不可能な気がする
カレントディレクトリをとるgetcwd()もPOSIX（unistd.h）だし
C言語の標準ライブラリにはディレクトリ階層の概念自体がなさそう

2021/07/28(水) 13:55:33.60

>>131
powershell と cmd で違うのか…
なんでそうしたんだろ
何れにしても、けぅこう面倒なのね

2021/07/28(水) 14:05:55.87

みなさんありがとうございます
dirname(argv[0]) したら argv[0] が壊れました
ほんとうにがりがとうございました

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd33-vTy/) · 2021/07/28(水) 14:19:05.25

本当のニガリが10、あったと？

2021/07/28(水) 14:21:25.34

これ解決策じゃなくて愚痴なんだが、main()関数が使えるのはホスト環境で、つまりmain()関数のargv[]引数は「OSによる支援」を前提にできるんだから、実装依存じゃなくて「argv[0]には実行されたファイルのOSにおけるパス名が格納される」みたいな仕様にしてもよかった気がする。
それこそstdint.hみたいに、多種多様な機器への対応を考えなくてもいい関数なんだから、実行環境のファイルシステムやらをある程度は仮定しちゃってもいいわけで。

2021/07/28(水) 16:21:41.95

ファイルシステムもOSもない組み込み機器もあるわけで・・・

2021/07/28(水) 16:21:59.41

>>136
どんな OS でも Unix 風のファイルシステムを採用しているというわけではなくて、
たとえば BTRON が採用しているファイルシステムでは
同名のファイルが存在してよく、ディレクトリのような階層化は存在しない。
全体で唯一に区別できる名前 (フルパスに相当するもの) がない。

OS だってファイルシステムだって多種多様なんで、
起動時に「なんらかの」文字列で情報が与えられるということ以上は
環境依存にならざるを得ないよ。

2021/07/28(水) 16:25:16.04

>>137
その場合は通常の main 関数からの起動にはならない (main に意味のある引数が渡されないか特別なスタートアップ経由で起動される)
ので、「main に値が渡されるならば」それなりの OS が仮定できるというのが >>136 の言ってることやで。

2021/07/28(水) 18:03:22.93

>>139
すげぇ
たまには正しくわかりやすい説明できんじゃん
ちょっと見直した

2021/07/28(水) 18:21:15.71

コード記述してて実行ファイルのフルパスが必要となるんだから
それなりのOSから叩き起こされてること前提よね

2021/07/28(水) 18:43:00.22

>>138
> BTRON が採用しているファイルシステムでは
> 同名のファイルが存在してよく、ディレクトリのような階層化は存在しない

知らんかった……。
調べたところBTRONは組込み機器向けのファームウェアじゃなさそうだし，
ホスト環境=「それなりのOSが期待できる」環境あっても，
「あるファイルのパス名が存在して，その絶対値が文字列として一意に定まる」
ことさえ期待できないのか……。

2021/07/28(水) 18:54:22.92

>>134
dirname()は引数を破壊するのでコピーしてから渡すべし
今回のケースでは結局ダメだけどｗ

2021/07/28(水) 18:56:43.36

> [...] the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program startup.

http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#section.5.1.2.2.1

C2xでもargv[0]に何が格納されるかは「実装依存」って書いてあるね……めちゃくちゃ残念だ。
あとこれ読んでて気が付いたけど，「ホスト環境」ってhost environmentじゃないのね。
hosted enviromentだから，正確に訳すなら「ホスト済み環境」とかのほうが良いのかな？

2021/07/28(水) 22:12:53.76

そのhosted environmentはプログラムの実行環境（execution environments）を
・freestanding（自立した環境＝OS無しの組み込み系）
・hosted（OSにhostされた環境）
に分けたものだからOSとかプラットフォームを指すホスト環境とはたぶん別の意味

2021/07/30(金) 19:40:44.58

hosted environmentの概念には明らかにUNIXが背景になってるね
MS-DOSだのCP/MだのROM BASICだのまでは想定してない

2021/07/31(土) 21:45:13.12

>>146
くわしくしりたいです。

「OSというのものは高性能である」という前提が
Unixとかでしか通用しなかったってことですか？

2021/08/01(日) 11:25:29.19

>>147
性能とかじゃなくてモデル化の仕方が多様という話。

たとえば古い時代の BASIC (N-BASIC など) は環境変数やコマンドラインという概念は持たないが、
違う形でデータを受け渡す方法は持っていて、どちらが高性能かというようなものではない。

2021/08/01(日) 18:29:17.83

>>148
今調べた知識なのでいろいろ間違っているとは思うのですが，
N-BASICとかってそもそも「OS」なんですかね……？

「hosted environmentという概念はUnixを想定したもので，
古いBASICでは通用しない」
という話からは，
1. Unixと古いBASICが同列の概念である
2. hosted environmentは「OSがある環境」を指している
ようなことが読み取れるんですが，

1. N-BASICはUnixのような
「機器→抽象化層1 (HAL/OS) →カーネル→シェル」
みたいな構造では表わせない位置にあるため
Unixと同列（あるいは類似）の概念として扱うのは
違うような気がすること

2. そもそもhosted environmentは
C2x規格の5.1.2.2で規定されている動作を実装した処理環境であって
「OSがある環境」を指してはいないこと
（だからUnixがどう，みたいな話は関係ない？）
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2596.pdf#paragraph.5.1.2.2

などから，ちょっと納得しがたいです……。

2021/08/01(日) 18:40:30.22

IPLで起動して、ハードウエアへのアクセスを代行し、
コマンドをタイプして結果を文字で表示するCUI
という観点からはUNIXとBASICは同列だよ

MS-DOSでのデバドラはお行儀でしかなく
アプリが直接I/Oなんて珍しくもなんともないが
一応argc, argvという概念はあった

言い出すとマイクロカーネルをヨイショする連中を嘲笑うように
モノリシックカーネルでいったLinuxは、じゃあOSに非ずなのかと

OSとは何か、何が該当し、何が該当しないのかは
見方が色々で誰もが認める基準はなかなかできない

2021/08/01(日) 19:45:48.16

なんかわざと煽ろうとしている？

2021/08/01(日) 20:00:02.07

OSから外れた例をわざわざ挙げたのだろうと思っていたが、OSが何か分からない人でしたか...

2021/08/01(日) 20:46:27.86

>>149
> N-BASICとかってそもそも「OS」なんですかね……？

---------- JIS X 0001-1994 ----------
オペレーティングシステム， OS（省略形）

プログラムの実行を制御するソフトウェアであって，
資源割振り,スケジューリング，入出力制御，
データ管理などのサービスを提供するもの。

備考
オペレーティングシステムは，ソフトウェアが主体であるが，
部分的にハードウェア化することも可能である。
-------------------------------------

まあ要するに OS がどのような構成を持つものなのかというのは曖昧で、
Unix 的な立ち位置も OS が持ちうる構成のひとつでしかないんよ。

> Unixと同列（あるいは類似）の概念として扱うのは
> 違うような気がすること

「モデル化の仕方は多様」という例のひとつとして N-BASIC を出している。
違うように感じられるならそれは提示した意図通り。

2021/08/01(日) 20:59:26.94

この人の理解が間違えている。
わざと言っているとしたら悪質

2021/08/01(日) 21:23:59.60

>>154
俺もわからん。
何がどう間違ってるのか説明しておくれ

2021/08/01(日) 21:37:13.51

N-BASICは確かにハードウエアを直接制御できるという意味では
OSに近い。ただ今のOSとは全然違う。BASICだと遅すぎるので
大半はマシン語で直接書いてある。今のOSとは考え方が違う。

2021/08/01(日) 21:43:51.38

BASICそのものはマシン語で書かれているんだが

2021/08/01(日) 21:54:08.54

>>156
たしかにそういう意味では「OS」といえるのかもしれないですね。
ただ，それだと組込み機器のファームウェアだって
機器を操作できる，対人インターフェースがあるという点ではOSといえることになりません？

2021/08/01(日) 21:58:23.19

なるね
何か困るの？

2021/08/01(日) 22:05:54.64

>>158
はっきりした基準はないという前提だけどぼんやりとした概念的な部分では
OS はアプリケーションソフトの対比的なものだと思う。
用途ごとのアプリケーションソフトを起動するという前提がないなら機能的に OS 相当のものを
含んでいても普通は OS とは言わないんじゃないかな。

2021/08/01(日) 23:18:55.12

ホントにOSだと主張するなら、ぜひWindowsの仮想環境で動かしてみてくれ

2021/08/02(月) 00:18:03.59

もしかして仮想マシンとエミュレータ混同してる？

2021/08/02(月) 00:39:04.73

動かせないのなら、回りくどい事言わず、無理ですと言えば済むよ

2021/08/02(月) 01:06:43.81

amd64で動くN-BASICがあるならできるんじゃない？
無いなら無理だわな

2021/08/02(月) 05:11:39.16

>>163
>>151

2021/08/02(月) 07:46:31.20

最近はスマホのカメラ部品にTRON OS入ってるんだって？
もうBIOSやファームウェアもOSになるんじゃないかとも思っちゃう。

2021/08/02(月) 10:11:13.69

>>152-153
BIOS: BI + OS
DOS: D + OS
OSとは

2021/08/02(月) 10:12:43.19

>>154
>わざと言っているとしたら悪質

ほんそれ
最近そういう書き込みが多い
5chから人を減らす作戦だろう

2021/08/02(月) 11:03:41.91

>>167
> BIOS: BI + OS
ネタか？
Basic Input/Output System やぞ

> DOS: D + OS
こっちは合ってる

2021/08/02(月) 12:33:14.68

>>169
もちろんネタと書いてあるのでネタなんでしょ。

2021/08/02(月) 13:13:02.28

Basic Interpreter OS

2021/08/02(月) 13:17:25.48

質問です
int flagA = 3 == 3;
int flagB = 3 == 3 == 3;
int flagC = 3 == 3 == 1;
の結果が
flagA : 1
flagB : 0
flagC : 1
になるのですが
flag B とか flag C は何が怒っているのでしょうか？

2021/08/02(月) 13:31:37.39

>int flagB = 3 == 3 == 3;
↓
int flagB = (3 == 3) == 3;
↓
int flagB = (1) == 3;
↓
int flagB = 0;

>int flagC = 3 == 3 == 1;
↓
int flagC = (3 == 3) == 1;
↓
int flagC = ( 1 ) == 1;
↓
int flagC = 1;

2021/08/02(月) 13:31:42.08

int flagD = 3 != 3;
int flagE = 3 != 3 == 0;
int flagF = 3 != 3 == 1;

flagD : 0
flagE : 1
flagF : 0
になります

2021/08/02(月) 13:31:46.39

タイホするっ！！　ダーン　ダーン

int flagB =
ここまでと
3 == 3 == 3
が別のパーツになっていて
== は左から結合するので
(3 == 3) == 3 となり真は1になるので
1 == 3 で偽すなわち0だ

2021/08/02(月) 13:41:18.14

解決しました
ありがとうございました

2021/08/02(月) 16:38:34.45

俺が怒っている

2021/08/02(月) 19:33:02.95

演算子の優先順位って覚えるのヤダー。自分書くと括弧だらけだわ。
どの辺が塩梅なんかねー？明示的でないと駄目よってコーディングとかもあるし。

2021/08/02(月) 19:49:19.60

それでいいよ

2021/08/02(月) 20:03:46.84

& ^ | なんかのビット演算が比較よか低いのが微妙に嫌

2021/08/03(火) 09:51:48.02

憶える気のない者は成長しない

2021/08/03(火) 10:01:19.19

結合の優先度は、自分が分かっていても
記憶があやふやな人が不安になるといけないから
結局カッコを明示的に描くかな…

2021/08/03(火) 10:17:52.20

中学のマイコン部かよ

2021/08/03(火) 13:41:40.87

>>181
覚える気があっても、覚えさせられる気がしねー。

2021/08/03(火) 13:45:58.11

自分を磨くのは本人なので
そんなお節介は考えなくていい

2021/08/03(火) 14:20:08.34

CでC++の純粋仮想関数のような事をやりたいのですができますか？　疑似インターフェースです。

2021/08/03(火) 14:30:35.30

typedef struct iunknown iunknown;

struct vtable
{
int (*query_interface)(iunknown*, int, void**);
int (*add_ref)(iunknown*);
int (*release)(iunknown*);
};

struct iunknown
{
long count;
vtable* vtbl;
};

みたいなことか？

2021/08/03(火) 14:31:17.98

あ、いかんvtableのtypedef忘れたけどまあ許せやｗ

2021/08/03(火) 14:32:38.22

のような事の解釈余地に幅がありすぎ

2021/08/03(火) 19:27:01.81

幅があると言うなら狭めるようなヒント書けばいいだけ
たたき台として>>187はそれほど悪くないと思う

2021/08/03(火) 20:41:05.50

>>187
スゴーイ　感謝感激　ありがとうございます。

typedef struct {
void (*interface_a)();
void (*interface_b();
,
.
} TINTERFACEXXX;

typedef struct {
TINTERFACE ia;

} TOBJA;

なんてリレーションスタイルも考えたんですが、
いずれにしろ、クリーンアーキテクチャーのCでのSOLID原則ができるというところまでこぎつけました。
ありがとうございます。

2021/08/03(火) 23:48:19.32

COM最強

**デフォルトの名無しさん** (JP 0Hee-YhuA) · 2021/08/05(木) 14:10:06.71

奥村晴彦『改訂新版 C言語による標準アルゴリズム事典』の
「改訂新版序」に、
> 現代の慣習に従って、[…] EXIT_SUCCESSを0にしたりした
とあるのですが、EXIT_SUCCESSマクロ変数を使った方が
定数即値を決め打ちするよりも可搬的であり、
それこそ「現代の慣習」であるように思うのですが、
実際はEXIT_SUCCESSより0を使う方が「現代的」なんですかね。

なお、誤植も疑ったのですが、集録されている実際のコードにおいても
return 0;と書かれていました。

2021/08/05(木) 14:30:14.22

>>193
0以外は1以上も-1以下もあるし、下手すりゃ数値以外の可能性すらあるけど
0 は絶対0なので、少なくともこれに関してだけは
私は許そう

**デフォルトの名無しさん** (JP 0Hee-YhuA) · 2021/08/05(木) 15:00:49.33

>>194
なるほど、「0 は絶対0なので」というので納得できました。
ありがとうございます。

2021/08/05(木) 15:20:09.93

>>193
思想的にはともかく、その件については習慣として定着してるという事実があるんで、
事実に逆らってもしょうがない。

ちなみに main 関数だけは return 文を通過せずに } に到達した場合には
return 0; と同じになるという仕様になってるんで、 return 文自体を省略するという
スタイルもある。

2021/08/05(木) 16:18:55.16

>>193
mainの出口は仕方ないんだよ
enumなんて考え方ができる遙か前に決まったことで今さら変えられないというのが現実だ

mainの第２引数だって今ならconst付けそうなところだけど
これまたconstなんかなかった頃に決まったことだ

2021/08/05(木) 17:17:51.97

>>197
歴史的にはそうなのかもしれないけど、それだと「EXIT_SUCCESSを0に」することが「現代の慣習」であることの説明になってなくないような
なんでEXIT_SUCCESSと書いてたのを0と書くようにしたのかが知りたいんでは
もう納得してるみたいなんでアレだけども

2021/08/05(木) 17:57:00.56

enumつったんだけど
話通じてねえな

2021/08/05(木) 18:23:46.65

マジックナンバーなんて駄目でしよってノリでEXIT_SUCCESSを使ってたけどあまり流行らなかったから0に戻したってことじゃないの？

2021/08/05(木) 18:25:20.09

>>199
マクロ (#define) の話だからenum関係ないよ

2021/08/05(木) 18:36:03.13

C言語7不思議

enum { A=1 } main(void) { return A; }

このコードは合法か否か？

2021/08/05(木) 18:54:07.04

法なんてない

2021/08/05(木) 20:40:48.16

>>200
だね
じゃあEXIT_SUCCESSはマジックナンバーないのかって

2021/08/05(木) 21:00:13.63

オレのばっちゃが決めたんだ

2021/08/05(木) 21:12:45.92

>>204
マジックナンバーって何かわかってる？
ググってからでないとenumみたいに頓珍漢なこと言って恥かくよ？

2021/08/05(木) 22:30:22.56

横だけどeasing関数でマジックナンバーっての見たけど、結局何だったのかわからないままですわ

2021/08/05(木) 22:33:51.51

線形合同法で作る乱数に出てくる謎定数

2021/08/06(金) 00:25:46.52

>>202
基本的には否だが、許容される場合はありうる。
main の型は以下のいずれか。

① int main(void);
② int main(int argc, char * argv[]);
③ 以上の二つのいずれかと等価 †1
④ 以上の三つのいずれでもない処理系定義の方法

それとは別に
「main関数の返却値の型がintと適合しない場合，ホスト環境に戻される終了状態は，未規定とする。」†2
とするという文言もある。
C で言う「未規定」というのは処理系が挙動を選択して良いことを意味するので、
適合しなくても適合したときと同等の処理になるように実装している処理系はあるかもしれない。

enum で定義した型 (列挙型) は
「char，符号付き整数型又は符号無し整数型と適合する型とする。型の選択は，処理系定義とする」 †3
とあり、列挙型が int と適合する可能性はある。

また、上述の④として処理系が main の返却値の型が列挙型であったときを許容するような定義をしているかもしれない。

-------------------------
†1 typedef やマクロによる別名、あるいは型調整などで同等になるものという意味
†2 「適合」に関する規則は複雑なのでここでは説明しない
†3 個別の列挙型ごとに選択してよい

2021/08/06(金) 07:01:45.65

>>206
おまえさんこそ何かわかってなさそうだな
なぜ、その値なのか由来が不明な定数は
スペルが0であろうがEXIT_SUCCESSであろうが
0x00であろうが本質的に同じことだぞ
UNIXを背景とせずにreturn 0;が説明できるか？

おまえさんみたいにググって拾った情報を丸呑みしてると
わかってないやつの間違った理解が伝搬するだけだぜ

2021/08/06(金) 08:15:51.79

>>210
EXIT_SUCCESSがどういう意味かもわからないなら英語からやり直せよw
値の話じゃないことぐらい理解しろ

非常に稀な例としてEXIT_SUCCESSが0でないシステムが存在する
例えばOpenVMSでは
EXIT_SUCCESS = 1
EXIT_FAILURE = 2
だったりする
http://fafner.dyndns.org/cgi-bin/conan.com?key=CRTL~exit%2C_exit~Argument&title=VMS%20Help

なのでそういうシステムへの移植を考えてるなら意味はあるけどそんな人はほとんどいないからreturn 0;でいいやんって話

そもそもunixでも0, 1以外の値を返すコマンドは多数あってその場合は自分でEXIT_xxxを定義する必要あるから0, 1だけ定義されててもねぇって感じもあるし

2021/08/06(金) 08:30:30.04

>>211
おまえさんは>>193が英語の話だと思っていたのかｗ
0がどういう意味かもわからないならCをやり直せよ

2021/08/06(金) 09:12:19.75

>>211
関係ない。言語仕様としては 0 が成功を表すというのは保証された動作で、
もしもホスト環境の都合と食い違うならランタイムサポート (スタートアップルーチン) で補正すべきこと。
EXIT_SUCCESS 「も」成功を意味する値として使えるというのとは独立した話。

2021/08/06(金) 09:17:08.98

>>212
まじでマジックナンバー知らんのか？

0じゃ何を意味するかわからんから名前をつけるって話だぞ
EXIT_SUCCESSが英語だから英語の勉強しろって言ってるだけ
日本語使える環境なら
　正常終了 = 0
でもいい

で、>>193の件はそうは言っても正常終了で0以外なんてまずないし、たいていの人はmain()が0を返したら正常終了ってわかるからreturn 0;でいいやってなってるだけ

2021/08/06(金) 09:19:10.68

>>213
> 関係ない。言語仕様としては 0 が成功を表すというのは保証された動作
どこで規定されてるのか示してみ
そもそもOpenVMSの処理系は規格違反とでも言うのかよw