I am getting confused with size_t in C. I know that it is returned by the sizeof operator. But what exactly is it? Is it a data type?

Let's say I have a for loop:

for(i = 0; i < some_size; i++)

Should I use int i; or size_t i;?

  • 6
    If those are your only options, use int if some_size is signed, size_t if it is unsigned. – Nate Mar 31 '10 at 5:59
  • 4
    @Nate That is incorrect. POSIX has a ssize_t type but the actually correct type to use is ptrdiff_t. – Steven Stewart-Gallus Mar 19 '17 at 18:46

12 Answers 12


From Wikipedia:

According to the 1999 ISO C standard (C99), size_t is an unsigned integer type of at least 16 bit (see sections 7.17 and 7.18.3).

size_tis an unsigned data type defined by several C/C++ standards, e.g. the C99 ISO/IEC 9899 standard, that is defined in stddef.h.1 It can be further imported by inclusion of stdlib.h as this file internally sub includes stddef.h.

This type is used to represent the size of an object. Library functions that take or return sizes expect them to be of type or have the return type of size_t. Further, the most frequently used compiler-based operator sizeof should evaluate to a constant value that is compatible with size_t.

As an implication, size_t is a type guaranteed to hold any array index.

  • 4
    "Library functions that take or return sizes expect them to be of type ... size_t" Except that stat() uses off_t for the size of a file – Draemon May 26 '10 at 22:12
  • 59
    @Draemon That comment reflects a fundamental confusion. size_t is for objects in memory. The C standard doesn't even define stat() or off_t (those are POSIX definitions) or anything to do with disks or file systems - it stops itself at FILE streams. Virtual memory management is completely different from file systems and file management as far as size requirements go, so mentioning off_t is irrelevant here. – jw013 Jun 10 '13 at 19:57
  • 3
    @jw013: I'd hardly call it a fundamental confusion, but you make an interesting point. Still, the quoted text doesn't say "sizes of in-memory objects", and "offset" is hardly a good name for a size type regardless of where it happens to be stored. – Draemon Jun 13 '13 at 22:50
  • 26
    @Draemon Good point. This answer quotes Wikipedia, which in this case doesn't have the best explanation, in my opinion. The C standard itself is much more clear: it defines size_t as the type of the result of the sizeof operator (7.17p2 about <stddef.h>). Section 6.5 explains exactly how C expressions work ( for sizeof). Since you cannot apply sizeof to a disk file (mostly because C doesn't even define how disks and files work), there is no room for confusion. In other words, blame Wikipedia (and this answer for quoting Wikipedia and not the actual C standard). – jw013 Jun 13 '13 at 22:57
  • 2
    @Draemon - I would also agree with the "fundamental confusion" assessment. If you haven't read the C/C++ standards, you might think "object" refers to "object oriented programming," which it does not. Read the C standard, which has none of those OOP objects, but yet has objects, and find out. The answer may surprise you! – Heath Hunnicutt Oct 29 '13 at 2:26

size_t is an unsigned type. So, it cannot represent any negative values(<0). You use it when you are counting something, and are sure that it cannot be negative. For example, strlen() returns a size_t because the length of a string has to be at least 0.

In your example, if your loop index is going to be always greater than 0, it might make sense to use size_t, or any other unsigned data type.

When you use a size_t object, you have to make sure that in all the contexts it is used, including arithmetic, you want non-negative values. For example, let's say you have:

size_t s1 = strlen(str1);
size_t s2 = strlen(str2);

and you want to find the difference of the lengths of str2 and str1. You cannot do:

int diff = s2 - s1; /* bad */

This is because the value assigned to diff is always going to be a positive number, even when s2 < s1, because the calculation is done with unsigned types. In this case, depending upon what your use case is, you might be better off using int (or long long) for s1 and s2.

There are some functions in C/POSIX that could/should use size_t, but don't because of historical reasons. For example, the second parameter to fgets should ideally be size_t, but is int.

  • 6
    @Alok: Two questions: 1) what is the size of size_t? 2) why should I prefer size_t over something like unsigned int? – Lazer Jun 8 '10 at 18:41
  • 1
    size_t isn't guaranteed to be the same thing as unsigned int (you seem to be implying that they're the same). – Brendan Long Jun 8 '10 at 19:11
  • 4
    @Lazer - yes, size_t is guaranteed to be an unsigned type. – Alok Singhal Jun 13 '10 at 14:37
  • 2
    @Celeritas no, I mean that an unsigned type can only represent non-negative values. I probably should have said "It can't represent negative values". – Alok Singhal Sep 28 '13 at 3:12
  • 2
    @JasonOster, two's complement is not a requirement in the C standard. If the value of s2 - s1 overflows an int, the behavior is undefined. – Alok Singhal Jul 6 '15 at 0:29

size_t is a type that can hold any array index.

Depending on the implementation, it can be any of:

unsigned char

unsigned short

unsigned int

unsigned long

unsigned long long

Here's how size_t is defined in stddef.h of my machine:

typedef unsigned long size_t;
  • 3
    Certainly typedef unsigned long size_t is compiler dependent. Or are you suggesting it is always so? – chux Oct 31 '14 at 18:48
  • 4
    @chux: Indeed, just because one implementation defines it as such doesn't mean all do. Case in point: 64-bit Windows. unsigned long is 32-bit, size_t is 64-bit. – Tim Čas Dec 28 '14 at 21:40
  • whats the purpose of size_t exactly? When I can create a variable for myself like: "int mysize_t;" or "long mysize_t" or "unsigned long mysize_t". Why should someone have created this variable for me? – midkin Jul 31 '16 at 20:18
  • @midkin size_t is not a variable. It's a type you can use when you want to represent the size of an object in memory. – Arjun Sreedharan Aug 1 '16 at 12:21
  • is it true that size_t is always 32bits on 32-bits machine, 64bits likewise? – John Wu Aug 24 '16 at 7:09

If you are the empirical type,

echo | gcc -E -xc -include 'stddef.h' - | grep size_t

Output for Ubuntu 14.04 64-bit GCC 4.8:

typedef long unsigned int size_t;

Note that stddef.h is provided by GCC and not glibc under src/gcc/ginclude/stddef.h in GCC 4.2.

Interesting C99 appearances

  • malloc takes size_t as an argument, so it determines the maximum size that may be allocated.

    And since it is also returned by sizeof, I think it limits the maximum size of any array.

    See also: What is the maximum size of an array in C?

  • 1
    I have the same environment, however, I've tested it for 32 bits, passing the GCC's "-m32" option, the result was: "typedef unsigned int size_t". Thanks for sharing this awesome command @Ciro, it helped me a lot! :-) – silvioprog Mar 21 '17 at 23:15
  • 2
    The matter itself is not confusing. It is the confusing mind that tries to ask many questions, and give many answers. I am surprised that this answer and the one by Arjun Sreedharan still do not stop people from asking and answering. – biocyberman Mar 31 '17 at 16:22
  • 1
    Great answer, because it actually tells you what size_t is, at least on a popular Linux distro. – Andrey Portnoy Jan 10 at 21:16

The manpage for types.h says:

size_t shall be an unsigned integer type


Since nobody has yet mentioned it, the primary linguistic significance of size_t is that the sizeof operator returns a value of that type. Likewise, the primary significance of ptrdiff_t is that subtracting one pointer from another will yield a value of that type. Library functions that accept it do so because it will allow such functions to work with objects whose size exceeds UINT_MAX on systems where such objects could exist, without forcing callers to waste code passing a value larger than "unsigned int" on systems where the larger type would suffice for all possible objects.

  • My question has always been: If sizeof never existed, would there be a need for size_t? – Dean P May 1 at 9:56
  • @DeanP: Perhaps not, though there would then be a question of what argument type should be used for things like malloc(). Personally, I would have liked to have seen versions which take arguments of type int, long, and long long, with some implementations promoting shorter types and others implementing e.g. lmalloc(long n) {return (n < 0 || n > 32767) ? 0 : imalloc(n);} [on some platforms, calling to imalloc(123) would be cheaper than calling lmalloc(123);, and even on a platform where size_t is 16 bits, code which wants to allocate size computed in a ` long` value... – supercat May 1 at 15:07
  • ...should be able to rely upon the allocation failing if the value is bigger than the allocator can handle. – supercat May 1 at 15:08

size_t and int are not interchangeable. For instance on 64-bit Linux size_t is 64-bit in size (i.e. sizeof(void*)) but int is 32-bit.

Also note that size_t is unsigned. If you need signed version then there is ssize_t on some platforms and it would be more relevant to your example.

As a general rule I would suggest using int for most general cases and only use size_t/ssize_t when there is a specific need for it (with mmap() for example).


To go into why size_t needed to exist and how we got here:

In pragmatic terms, size_t and ptrdiff_t are guaranteed to be 64 bits wide on a 64-bit implementation, 32 bits wide on a 32-bit implementation, and so on. They could not force any existing type to mean that, on every compiler, without breaking legacy code.

A size_t or ptrdiff_t is not necessarily the same as an intptr_t or uintptr_t. They were different on certain architectures that were still in use when size_t and ptrdiff_t were added to the Standard in the late ’80s, and becoming obsolete when C99 added many new types but not gone yet (such as 16-bit Windows). The x86 in 16-bit protected mode had a segmented memory where the largest possible array or structure could be only 65,536 bytes in size, but a far pointer needed to be 32 bits wide, wider than the registers. On those, intptr_t would have been 32 bits wide but size_t and ptrdiff_t could be 16 bits wide and fit in a register. And who knew what kind of operating system might be written in the future? In theory, the i386 architecture offers a 32-bit segmentation model with 48-bit pointers that no operating system has ever actually used.

The type of a memory offset could not be long because far too much legacy code assumes that long is exactly 32 bits wide. This assumption was even built into the UNIX and Windows APIs. Unfortunately, a lot of other legacy code also assumed that a long is wide enough to hold a pointer, a file offset, the number of seconds that have elapsed since 1970, and so on. POSIX now provides a standardized way to force the latter assumption to be true instead of the former, but neither is a portable assumption to make.

It couldn’t be int because only a tiny handful of compilers in the ’90s made int 64 bits wide. Then they really got weird by keeping long 32 bits wide. The next revision of the Standard declared it illegal for int to be wider than long, but int is still 32 bits wide on most 64-bit systems.

It couldn’t be long long int, which anyway was added later, since that was created to be at least 64 bits wide even on 32-bit systems.

So, a new type was needed. Even if it weren’t, all those other types meant something other than an offset within an array or object. And if there was one lesson from the fiasco of 32-to-64-bit migration, it was to be specific about what properties a type needed to have, and not use one that meant different things in different programs.


In general, if you are starting at 0 and going upward, always use an unsigned type to avoid an overflow taking you into a negative value situation. This is critically important, because if your array bounds happens to be less than the max of your loop, but your loop max happens to be greater than the max of your type, you will wrap around negative and you may experience a segmentation fault (SIGSEGV). So, in general, never use int for a loop starting at 0 and going upwards. Use an unsigned.

  • 2
    I cannot accept your argumentation. You say it is better that the overflow bug silently leads to accessing valid data within your array? – maf-soft May 10 '16 at 13:55
  • 1
    @maf-soft is correct. if the error goes undetected it makes it worse than a program crash. why did this answer got upvotes? – yoyo_fun Mar 15 '17 at 21:11
  • If it accesses valid data in your array then it's not a bug because unsigned type won't overflow at the limit signed type will. What is this logic guys? Let's say for some reason you use char to iterate over 256 element array... signed will overflow at 127 and 128th element will sigsegv, but if you use unsigned, then it will go through entire array as intended. Then again, when you are using an int, your arrays won't really be bigger than 2 billion elements so either way it does not matter... – Purple Ice Oct 28 '18 at 14:30
  • I can't imagine any situation in which integer overflow isn't a bug, whether it wraps around positive or negative. Just because you don't get a segfault doesn't mean you see correct behavior! And you can experience a segmentation fault, or not, whether your offset is positive or negative; it all depends on your memory layout. @PurpleIce, I don't think you're saying the same thing as this answer; your argument looks to be that you should choose a data type large enough to hold the largest value you want to put in it, which is just plain common sense. – Soren Bjornstad Apr 1 at 11:17
  • That said, I do prefer using an unsigned type for loop indices semantically; if your variable is never going to be negative, then you might as well indicate that in the type you choose. It could also allow the compiler to spot a bug where the value ended up negative, though GCC at least is pretty terrible at spotting this particular mistake (on one occasion I initialized an unsigned to -1 and didn't get a warning). Similarly, a size_t is semantically appropriate for array indices. – Soren Bjornstad Apr 1 at 11:17

size_t is unsigned integer data type. On systems using the GNU C Library, this will be unsigned int or unsigned long int. size_t is commonly used for array indexing and loop counting.



When we use a size_t object, we have to make sure that in all the contexts it is used, including arithmetic, we want only non-negative values. For instance, following program would definitely give the unexpected result:

// C program to demonstrate that size_t or
// any unsigned int type should be used 
// carefully when used in a loop

int main()
const size_t N = 10;
int a[N];

// This is fine
a[n] = n;

// But reverse cycles are tricky for unsigned 
// types as can lead to infinite loop

Infinite loop and then segmentation fault

From my understanding, size_t is an unsigned integer whose bit size is large enough to hold a pointer of the native architecture.


sizeof(size_t) >= sizeof(void*)
  • 15
    Not true. The pointer size can be bigger than the size_t. Several example: C compilers on x86 real mode can have 32 bit FAR or HUGE pointers but size_t is still 16 bits. Another example: Watcom C used to have a special fat pointer for extended memory that was 48 bits wide, but size_t was not. On embedded controller with Harvard architecture, you have no correlation either, because both concerns different address spaces. – Patrick Schlüter Jul 26 '13 at 12:26
  • 1
    And on that stackoverflow.com/questions/1572099/… there are more examples AS/400 with 128 bit pointers and 32 bit size_t – Patrick Schlüter Jul 26 '13 at 12:30
  • This is blatantly false. However, let's keep it here – Antti Haapala Oct 16 '17 at 7:53

protected by Antti Haapala Oct 16 '17 at 7:54


Would you like to answer one of these unanswered questions instead?
