10

これは、ファイル inode に関する情報の構造を参照しています。

 dev_t       st_dev;     /* ID of device containing file */
 ino_t       st_ino;     /* inode number */
 mode_t      st_mode;    /* protection */
 nlink_t     st_nlink;   /* number of hard links */
 uid_t       st_uid;     /* user ID of owner */
 gid_t       st_gid;     /* group ID of owner */
 dev_t       st_rdev;    /* device ID (if special file) */
 off_t       st_size;    /* total size, in bytes */
 time_t      st_atime;   /* time of last access */
 time_t      st_mtime;   /* time of last modification */
 time_t      st_ctime;   /* time of last status change */
 blksize_t   st_blksize; /* blocksize for filesystem I/O */
 blkcnt_t    st_blocks;  /* number of blocks allocated */

私は本当にあらゆるタイプの答えを探しています。すべてのフィールドがで始まることに気付きst_ましたが、インターネット上で適切な説明を見つけることができません。

4

3 に答える 3

19

これは、最初の C バージョンにまでさかのぼります。構造体メンバー用の個別のシンボル テーブルはありませんでした。名前はグローバル シンボル テーブルに追加されました。明らかに厄介なグローバル名前空間の汚染が原因です。回避策は、今日列挙型で使用するものと同じで、名前の衝突を避けるために数文字を前に付けます。

歴史的な記録のようなものです。この種のメンバー名を持つ構造体を見ると、それが古いことがわかります。

于 2012-04-26T01:07:26.207 に答える
4

ハンスの答えに加えて、名前の衝突はまだ現実のものだと思います。最新の Cstructフィールドはグローバル名前空間にありませんが、マクロ定義と競合する可能性があります。

これは、通常、誰もがマクロに大文字を使用し、他の識別子に小文字を使用する理由の 1 つですが、残念ながらこれが常に可能であるとは限りません。C ライブラリ自体には、小文字のマクロがあります。基本的に、ライブラリ内のすべての関数には、最適化のために関数を「オーバーロード」する対応するマクロがあります。あなたの例では、C（POSIXなど）で関数が表示されることを簡単に想像できますblksize。ある日、その関数をオーバーロードしたいメンバーのst_プレフィックスがない場合、問題が発生します。stat

C11 とそのタイプの汎用マクロでは、そのよう_Genericなマクロを使用することがさらに一般的になります。そのため、識別子の選択方法を把握していない多くのコードで使用されるライブラリを設計している場合でも、そのような命名規則を使用する方が適切です。

これはすべて、structメンバーだけでなく、関数のパラメーター名と変数にも適用されinlineます。

于 2012-04-26T06:32:30.490 に答える
0

st_... が表示されたときに、それが stat 構造 (st で始まる) の一部であることがわかるように、これは命名規則であると思います。

于 2012-04-26T00:58:47.387 に答える