結局何がわかれば満足かが今ひとつ...その辺全部すっきりさせなきゃいけないのかな。ちょっと大変。
まずひとつ根本的な話。
C言語ってのは、すご～く原始的な言語で、1970年代のコンピュータの能力を骨の髄まで絞り出すために「コンピュータの中身」をさらけ出していて、いろいろなことをプログラマが面倒みてやらなきゃいけません。基本的に人間の都合ではなく、コンピュータの都合が原則で、優先。これを忘れないで下さい。「なんでそうなってるの？」と思ったら、それは「コンピュータにとってそれが都合がいい(よかった)から」が答えです。
で。そんなC言語は、「配列」というものをその構成要素がメモリ上に密に並んだもの、と定義しました。配列を変数として定義すると、その要素数のメモリエリアを変数の領域として確保したコードを出力します。ここで注意が必要なのは、C言語がやってくれるのは「領域を確保する」だけ。要素数の管理は全てプログラマの責任です。なんでそうなっているのか...もちろん「コンピュータで要素数の管理をすると言語の処理が面倒になるから」。
なので、「配列」としてC言語が管理するのは最初の要素の位置(アドレス)すなわちポインタだけ。2番目以降の要素は、(要素が密に並んでいるというのが配列の定義ですから)最初の要素の位置に要素のサイズを足していけば在処がわかるのでアクセスできる、ということになります。
で、配列で管理するのがポインタだけなら、つまりそれはポインタと一緒だよね、ということで、
・配列として宣言した変数名は最初の要素へのポインタとして扱われる
・関数の引数の型として配列を指定することと、ポインタを指定することは等価
ということにしました。そう決めたのだから文句を言わないで従って下さい。
これらにより
\u0026gt; 引数として、配列名だけを渡していること
\u0026gt; int *となっていないこと
の理由付けがされます。配列名は即ちポインタ型で、int*とint[]型は等価なのですから。
さて。
配列を受け渡しするときに配列の長さを指定していないこと
は、一般的にはよろしくないことですが、場合によってはあり、です。
それでいい場合というのは、
・プログラム上で配列のサイズがハードコーディングされている。呼び出し側と関数側とがそれぞれ配列のサイズを「知っている」=ソースコード上にかかれている
・配列の内容自身に、たとえば「負のデータが出てきたら配列終わり」などの規則が設けられていて結果として配列のサイズがわかる(呼び出し側と関数側どちらもがその規則を守っている)
といったところでしょう。
これは、もとの課題設定がどのようなものかまで遡って考えないと、この質問からだけでは正否は判断できません。
また、
\u0026gt; int x;と定義して、\u0026amp;xが0x1000なら、x[1]とやったら0x1004を参照できるのか？
C言語の範囲では、少なくとも参照しようとはします。それが許される動作となるかどうかはまた別の議論で、C言語の範囲外で決まること。そして参照した結果起こることは「プログラマの責任」とされています。
ところで、いくつか本題とは関係ないコメント。
・C言語においては、「宣言」と「定義」という言葉は意味が異なります。混同しないようにしましょう。
\u0026gt; 関数の定義はこうなるそうです。
\u0026gt; void times(int samp[]);
これは「こういう関数があるよ」という「宣言」であって、「その関数はこう動くよ」という「定義」ではありません。
また、
\u0026gt; 配列の定義時に配列の長さを定義していない
例えば
int array[];
として配列を「定義」しようとするとエラーになります。配列の定義時には配列のサイズは指定されているはずです。
なお、関数の(仮)引数は、これも「こういう変数があるよ」という「宣言」であって、定義ではありません。「これは配列だからね」という情報(=宣言)だけあれば、先に述べたようにCではサイズは管理しないので無意味です(一応数字を書くことは許されていますが無視されます)。
もう一つ、int型のサイズは必ずしも4byteではありません。現在メジャーな処理系では4byteかも知れませんが、それは今どきのCPUがそれが都合が良い、という理由によるものです。C言語としてはint型は16bit以上の値の範囲を表せればよい、ということになっています。sizeof(int)は4と思い込みませんように。
