C言語でchar型のポインタの初期値について

Question

C言語で以下のようなソースを作成したのですが
一点疑問がでてきました。

#include <stdio.h>
#include <stdlib.h>



int main (int argument_count, char *argument_string[]) {

  char *path;
  for (int i = 0; i < argument_count; i++) {
    path = argument_string[i];
    printf("%s", path);
  }
  return 0;
}

上記のようにコンパイル後に上記バイナリを実行時，
コマンドライン引数を char *path と宣言された pathという変数にコマンド引数を代入して
出力していますが，この時ポインタ変数のメモリ確保を行っていないのですが，windowsのコマンドプロンプト上では
問題なくコマンドライン引数が出力されてしましました。

疑問点は ポインタ変数は初期化せずに動的にどのようなバイト数の文字列も格納できるのでしょうか？

Answer 1

ポインタ変数は初期化せずに動的にどのようなバイト数の文字列も格納できるのでしょうか？

は、間違っています。ポインタ変数に文字列はどんなものであっても格納できません。

ポインタ変数には、どのようなバイト数の文字列を指すポインタも格納できる

というのが正しいです。
なので、そのプログラムは正常に動きます。

Answer 2

どうもC初心者あるあるネタの配列とポインタと文字列がごっちゃになっているパターンかと思われますね。

配列

配列とはある一つの型のデータが任意個数連続して並んでいる領域のことです。

int arr[3];//int型のデータが3個連続して並んでいる領域

配列型の重要な性質として、式中では3つの例外を除き配列型はつねにポインタ型に読み替えられると言うものがあります。つまり配列のある領域をさすポインタとして解釈されるということです。

int arr[3];
arr;//arrはint[3]型なんだけどint*型として解釈される
sizeof(arr);//sizof演算子は3つの例外の一つ

文字列リテラル

"arikitari";//char配列型、処理系依存の型
u8"ありきたりなせかい";//const char[28]型
L"????";//wchar_t配列型、処理系依存の型
u"????";//const char16_t[3]型
U"????";//const char32_t[2]型

こんなやつらです。

([C++11～]const修飾された)配列型になります。

u8/u/Uはprefixといって、これがつくと文字列リテラルはそれぞれUTF-8/UTF-16/UTF-32でエンコードされます。
Lもprefixですが、Unicodeのどのエンコードが使われるかは決まっていません。一般にはUTF-16(Windows)/UTF-32(Linux)が用いられます。
prefixがついていない文字列リテラルの文字コードは処理系依存です。

要素数は文字エンコードした時のCode units数+1(NULL文字分)になります。

Code unitsについては
http://unicode.org/faq/char_combmark.html#7
を参照してください。

文字列リテラルは配列型なので先に述べたとおり3つの例外を除きポインタ型に読み替えられます。

u8"ありきたりなせかい";//const char[28]型なんだけどconst char*型として扱われる
const char* str;
//文字列リテラルはconst char*型として扱われるので、
//文字列リテラルは文字列が格納された領域へのポインタとして解釈されている。
//このポインタを変数strに代入しているが、これはポインタのコピー。
str = u8"ありきたりなせかい";

多くの場合、文字列リテラルはコンパイルしてできた実行ファイル中にエンコード済みの形で埋め込まれ、実行時は読み出し専用のメモリー領域に配置されます。

問題のプログラムを解釈してみる

#include <stdio.h>
#include <stdlib.h>

//文字列が格納された領域を指すポインタの配列へのポインタが
//プログラム実行時、main関数が呼ばれる時にargument_stringに渡される
int main (int argument_count, char *argument_string[]) {

  char *path;
  for (int i = 0; i < argument_count; i++) {
    //これはただのポインタのコピー
    path = argument_string[i];
    printf("%s", path);
  }
  return 0;
}

Answer 3

mainには、「既に確保され、コマンドラインの内容がコピーされている」argvが渡されます。それを参照するのはもちろん合法です。そしてpathも「初期化していますから」それを参照するのも合法です。

Answer 4

ポインタ変数が格納しているのは文字列ではなく、その文字列のアドレスです。
どのような長さの文字列であっても、その先頭のアドレスは一定のサイズで表現可能です。
ですから、ご提示のコードは正しく動作します。

---

嬉しいことに、有益なコメントを皆様書き込んでくださいました。
そちらも併せてごらんくださいね。

Comments

[退会済みユーザー]

ご回答ありがとうございます。

>ポインタ変数が格納しているのは文字列ではなく、その文字列のアドレスです。
これって
path = argument_string[i];
を
path = "あいうえお";
とした場合，この「あいうえお」とは

つまり，
char s[] = {"文字列"};
printf("%p", &s); // 出力は => 0028FF22
のように出力される「0028FF22」がアドレス値であるように
「あいうえお」もアドレス値と呼べるということなのでしょうか？？

[LouiS0616]

いや、”あいうえお”はアドレス値とは呼べません。それはリテラルです。
文字列リテラルをポインタ変数に代入しようとすると、文字列自体ではなく先頭のアドレスが代入されるようになっています。
sizeof演算子を用いて試してみると、どのような長さの文字列でポインタ変数を初期化しても、その変数のサイズが変わらないことがわかります。

[LouiS0616]

あと、ご提示の以下のコードは何か変ですね。
char s[] = {"文字列"};
printf("%p", &s);
文字列の配列を使いたいなら二次元配列を用いるべきです。
そのあとのprintf関数もちょっとあやしいです。

[SaitoAtsushi]

文字列リテラルというのは型で言えばあくまで char の配列なんですが、状況がそろうと勝手にポインタに変換されるんです。 このあたり、 C だと暗黙の型変換でうまいこと処理されちゃうんでどうなってるのかかえって分かり難いんですよね……。

[rubato6809]

メモリの図を描くことが、Cでは特に大事なんですよ。
ふつうの変数・文字列配列・ポインタ変数・ポインタの配列などが、メモリ上でどんな姿をしているか、どれだけのバイト数を必要とするか、どんな配置になるか・・・かなり具体的にイメージできるものなのですが、それが出来るかどうか。この場合も
path = argument_string[i];　を図に描いてみる。

プログラムの字面や言葉で理解しようとしても限界がある。少なくとも、理解できるまで時間がかかってしまう。百聞は一見に如かず。

[nagaetty]

同じく「メモリの図を描く」ことはC言語を理解する場合はとても良い事です。下記が図解されていて良いかもしれません。
https://www.grapecity.com/tools/support/powernews/column/clang/028/page02.htm

[LouiS0616]

私自身もとても勉強になります。コメントありがとうございます。

Answer 5

char* path;

このようなブロック内での変数宣言は auto 変数といって、宣言された時点でメモリ（あるいはCPUレジスタ）が確保されます。
ただし、確保されたのはポインタ変数であって、そのポインタ変数が示す先については未定義です。
※宣言時点で null に初期化されている場合もあるが、C コンパイラの実装に依存するためそれを期待してはいけません

char* msg = "あいうえお";

これはまず、"あいうえお"というのをメモリのどこかに確保し、そのメモリアドレスを、ポインタ変数に初期値として代入しています。
※実際の"あいうえお"のメモリ部分は、プログラムの実行ファイル内のデータ専用領域に（コンパイルされた時点で）確保され存在しています。ので、プログラムをロードした時点で確保済みです。
つまりこの場合、メモリは2か所（ポインタ変数の分と、その示す先の文字列分）確保されています。