When to cast size_t

Question

I'm a little confused as how to use size_t when other data types like int, unsigned long int and unsigned long long int are present in a program. I try to illustrate my confusion minimally. Imagine a program where I use

void *calloc(size_t nmemb, size_t size)

to allocate an array (one- or multidimensional). Let the call to calloc() be dependent on nrow and sizeof(unsigned long int). sizeof(unsigned long int) is obviously fine because it returns size_t. But let nrow be such that it needs to have type unsigned long int. What do I do in such a case? Do I cast nrow in the call to calloc() from unsigned long int to size_t?

Another case would be

char *fgets(char *s, int size, FILE *stream)

fgets() expects type int as its second parameter. But what if I pass it an array, let's say save, as it's first parameter and use sizeof(save) to pass it the size of the array? Do I cast the call to sizeof() to int? That would be dangerous since int isn't guaranteed to hold all possible returns from sizeof().

What should I do in these two cases? Cast, or just ignore possible warnings from tools such as splint?

Here is an example regarding calloc() (I explicitly omit error-checking for clarity!):

long int **arr;
unsigned long int mrow;
unsigned long int ncol;

arr = calloc(mrow, sizeof(long int *));

for(i = 0; i < mrow; i++) {
        arr[i] = calloc(ncol, sizeof(long int));
}

Here is an example for fgets() (Error-handling again omitted for clarity!):

char save[22];
char *ptr_save;
unsigned long int mrow
if (fgets(save, sizeof(save), stdin) != NULL) {
        save[strcspn(save, "\n")] = '\0';
        mrow = strtoul(save, &ptr_save, 10);
}

Answer 1

I'm a little confused as how to use size_t when other data types like int, unsigned long int and unsigned long long int are present in a program.

It is never a good idea to ignore warnings. Warnings are there to direct your attention to areas of your code that may be problematic. It is much better to take a few minutes to understand what the warning is telling you -- and fix it, then to get bit by it later when you hit a corner-case and stumble off into undefined behavior.

size_t itself is just a data-type like any other. While it can vary, it generally is nothing more than an unsigned int covering the range of positive values that can be represented by int including 0 (the type size was intended to be consistent across platforms, the actual bytes on each may differ). Your choice of data-type is a basic and fundamental part of programming. You choose the type based on the range of values your variable can represent (or should be limited to representing). So if whatever you are dealing with can't be negative, then an unsigned or size_t is the proper choice. The choice then allows the compiler to help identify areas where your code would cause that to be violated.

When you compile with warnings enabled (e.g. -Wall -Wextra) which you should use on every compile, you will be warned about possible conflicts in your data-type use. (i.e. comparison between signed and unsigned values, etc...) These are important!

Virtually all modern x86 & x86_64 computers use the twos-compliment representation for signed values. In simple terms it means that if the leftmost bit of a signed number is 1 the value is negative. Herein lie the subtle traps you may fall in when mixing/casting or comparing numbers of varying type. If you choose to cast an unsigned number to a signed number and that number happens to have the most significant bit populated, your large number just became a very small number.

What should I do in these two cases? Cast, or just ignore possible warnings...

You do what you do each time you are faced with warnings from the compiler. You analyze what is causing the warning, and then you fix it (or if you can't fix it -- (i.e. is comes from some library you don't have access to) -- you understand the warning well enough that you can make an educated decision to disregard it knowing you will not hit any corner-cases that would lead to undefined behavior.

In your examples (while neither should produce warning, they may on some compilers):

arr = calloc (mrow, sizeof(long int *));

What is the range of sizeof(long int *)? Well -- it's the range of what the pointer size can be. So, what's that? (4 bytes on x86 or 8 bytes on x86_64). So the range of values is 4-8, yes that can be properly fixed with a cast to size_t if needed, or better just:

arr = calloc (mrow, sizeof *arr);

Looking at the next example:

char save[22];
...
fgets(save, sizeof(save), stdin)

Here again what is the possible range of sizeof save? From 22 - 22. So yes, if a warnings is produced complainting about the fact that sizeof returns long unsigned and fgets calls for int, 22 can be cast to int.

Answer 2

When to cast size_t

You shouldn't.

Use it where it's appropriate.

• (As you already noticed) the libc-library functions tell you where this is the case.
• Additionally use it to index arrays.

---

If in doubt the type suits your program's needs you might go for the useful assertion statement as per Steve Summit's answer and if it fails start over with your program's design.

---

More on this here by Dan Saks: "Why size_t matters" and "Further insights into size_t"