size_t 與 ssize_t的解釋

 

ssize_t是什麼類型的？

解釋一：為了增強程式的可移植性，便有了size_t，它是為了方便系統之間的移植而定義的，不同的系統上，定義size_t可能不一樣。

     在32位系統上 定義為 unsigned int 也就是說在32位系統上是32位無符號整形。在64位系統上定義為 unsigned long 也就是說在64位系統上是64位無符號整形。size_t一般用來表示一種計數，比如有多少東西被拷貝等。例如：sizeof操作符的結果類型是size_t，該類型保證能容納實現所建立的最大對象的位元組大小。 它的意義大致是“適於計量記憶體中可容納的資料項目個數的不帶正負號的整數類型”。所以，它在數組下標和記憶體管理函數之類的地方廣泛使用。而ssize_t這個資料類型用來表示可以被執行讀寫操作的資料區塊的大小.它和size_t類似,但必需是signed.意即：它表示的是signed
size_t類型的。

typedef unsigned long size_t

解釋二：ssize_t是signed size_t，

size_t是標準C庫中定義的，應為unsigned int。定義為typedef int ssize_t。

而ssize_t:這個資料類型用來表示可以被執行讀寫操作的資料區塊的大小.它和size_t類似,但必需是signed.意即：它表示的是sign size_t類型的。

《Unix 進階環境編程》裡面是這麼說的：

原始系統資料類型
前面所示的g e t p i d函數的原型定義了其傳回值為p i d _ t類型，這也是P O S I X中的新規定。
U N I X的早期版本規定此函數返回一整型。與此類似， r e a d和w r i t e傳回型別為s s i z e _ t的值，並
要求第三個參數的類型是s i z e _ t。
以_ t結尾的這些資料類型被稱為原始系統資料類型。它們通常在標頭檔< s y s / t y p e s . h >中定
義(標頭檔< u n i s t d . h >應已包括該標頭檔)。它們通常以C typedef說明加以定義。t y p e d e f說明在C
語言中已超過1 5年了(所以這並不要求ANSI C)，它們的目的是阻止程式使用專門的資料類型
(例如i n t , s h o r t或long) 來允許對於一種特定系統的每個實現選擇所要求的資料類型。在需要儲存
進程I D的地方，配置類型為p i d _ t的一個變數(注意，程式1 - 5已對名為p i d的變數這樣做了)。在
各種不同的實現中，這種資料類型的定義可能是不同的，但是這種差別現在只出現在一個頭文
件中。我們只需在另一個系統上重新編輯應用程式。

 This's a way of defining size_t and ssize_t in Linux:

 //"linux/types.h"
 typedef __kernel_size_t size_t;
 typedef __kernel_ssize_t ssize_t;
 //"asm/posix_types.h"
typedef unsigned int __kernel_size_t;
 typedef int __kernel_ssize_t;

 It seems so tricky to me. What benefits do we get from such a tricky
 typedef ? better name (size_t is shorter than unsigned int) ?[/color]

On some 64-bit platforms, 'int' and 'unsigned int' may be 32-bits,
while addresses and even memory sizes could require 64 bits
(e.g. for the size of an allocated memory block > 4GB).
On such platforms, size_t could be typedef'd to a different
type, such as 'unsigned long long'.

Note also that 'size_t' is a typedef required by the ISO C standard
(it must be available if <stddef.h> is included). However, 'ssize_t'
does not exist in the C standard -- the standard 'ptrdiff_t'
typedef is nearly equivalent.