Is size_t the word size?

前端 未结 6 2119
有刺的猬
有刺的猬 2021-02-06 23:27

Is size_t the word size of the machine that compiled the code?

Parsing with g++, my compiler views size_t as an long unsigned int

6条回答
  •  生来不讨喜
    2021-02-07 00:06

    No; size_t is not necessarily whatever you mean by 'the word size' of the machine that will run the code (in the case of cross-compilation) or that compiled the code (in the normal case where the code will run on the same type of machine that compiled the code). It is an unsigned integer type big enough to hold the size (in bytes) of the largest object that the implementation can allocate.


    Some history of sizeof and size_t

    I don't know when size_t was introduced exactly, but it was between 1979 and 1989. The 1st Edition of K&R The C Programming Language from 1978 has no mention of size_t. The 7th Edition Unix Programmer's Manual has no mention of size_t at all, and that dates from 1979. The book "The UNIX Programming Environment" by Kernighan and Pike from 1984 has no mention of size_t in the index (nor of malloc() or free(), somewhat to my surprise), but that is only indicative, not conclusive. The C89 standard certainly has size_t.

    The C99 Rationale documents some information about sizeof() and size_t:

    6.5.3.4 The sizeof operator

    It is fundamental to the correct usage of functions such as malloc and fread that sizeof(char) be exactly one. In practice, this means that a byte in C terms is the smallest unit of storage, even if this unit is 36 bits wide; and all objects are composed of an integer number of these smallest units. Also applies if memory is bit addressable. C89, like K&R, defined the result of the sizeof operator to be a constant of an unsigned integer type. Common implementations, and common usage, have often assumed that the resulting type is int. Old code that depends on this behavior has never been portable to implementations that define the result to be a type other than int. The C89 Committee did not feel it was proper to change the language to protect incorrect code.

    The type of sizeof, whatever it is, is published (in the library header ) as size_t, since it is useful for the programmer to be able to refer to this type. This requirement implicitly restricts size_t to be a synonym for an existing unsigned integer type. Note also that, although size_t is an unsigned type, sizeof does not involve any arithmetic operations or conversions that would result in modulus behavior if the size is too large to represent as a size_t, thus quashing any notion that the largest declarable object might be too big to span even with an unsigned long in C89 or uintmax_t in C99. This also restricts the maximum number of elements that may be declared in an array, since for any array a of N elements,

    N == sizeof(a)/sizeof(a[0])

    Thus size_t is also a convenient type for array sizes, and is so used in several library functions. [...]

    7.17 Common definitions

    is a header invented to provide definitions of several types and macros used widely in conjunction with the library: ptrdiff_t, size_t, wchar_t, and NULL. Including any header that references one of these macros will also define it, an exception to the usual library rule that each macro or function belongs to exactly one header.

    Note that this specifically mentions that the was invented by the C89 committee. I've not found words that say that size_t was also invented by the C89 committee, but if it was not, it was a codification of a fairly recent development in C.


    In a comment to bmargulies answer, vonbrand says that 'it [size_t] is certainly an ANSI-C-ism'. I can very easily believe that it was an innovation with the original ANSI (ISO) C, though it is mildly odd that the rationale doesn't state that.

提交回复
热议问题