Hello,
gcc 4.4.1 C99
I am using size_t and size_t is a unsigned int. However, that depends if you are running 32 bit or 64 bit.
I will be using size_t to store the size of a buffer.
So I don't think this would be very portable if using across architectures.
Just a question, with using size_t on either a 32 or 64 bit. What situations would cause the most serious problem?
Many thanks,
The only real serious problem with this is trying to access a rather large array or a large number for size_t.
Just like just a regular "int" might be enough on a 64-bit, but could cause a crash on a 32-bit because its too large for a int on a 32-bit system.
It makes some sense to use size_t or ssize_t for a buffer if you're using malloc() or read(). For portability use SIZE_MAX, SSIZE_MAX, sizeof(type-in-your-buffer) and %zd or %zu printf().
You should not assume that size_t is an unsigned int (see this answer), but I think it is has the same range on both architectures.
Depends on what you are using size_t for.
If you use it to determine the size of a memory buffer it will be safe, since size_t is large enough to address the whole memory of any computer. So if the memory buffer is larger than that, you have a problem anyway.
On the other hand, if you use it as a generic unsigned integer to count the number of stars in the universe for example, you might have a problem on 32-bit system (not sure about 64-bit systems).
You've also got off_t and ptrdiff_t / ssize_t, which vary between architectures in the same way.
If you use them correctly, then they are portable across architectures. On a 32-bit system, they'll all be 32 bits wide, while on a 64 bit system they will all be 64 bits wide. This is what you want - the size of a buffer can't possibly be any larger than a 32-bit size_t on a 32-bit system, but it can be far larger on a 64-bit system.
You should never use ints, longs, or anything else. Aside from anything else, the size of a long varies depending on the platform (32-bits on most 32-bit systems, 64-bits on 64-bit Unix systems, 32-bit on 64-bit Windows).
It is hard to figure out what you mean by "portable" in this case. The term "portable" allows multiple sinificantly different interpretations.
Type size_t has a very specific purpose. It can hold the size of any object in the given implementation. I.e. it is a type that can always receive the result of sizeof() operator. Type size_t has no other purpose, and within its intended application it is 100% portable, as portable as anything can be.
What kind of "portable" you are asking about is, once again, not clear.
size_t is guaranteed to be able to hold the number of bytes of any object on your implementation.
That's why the return type of sizeof is size_t.
So yes, it's portable.
As others have said, size_t is correct and perfectly acceptable for storing the result of sizeof() or the size of any representable object in bytes. What you have to watch out for is the following:
size_t is the same size as some unsigned integer type. It is not necessarily the same number of bytes as the largest unsigned integer type, unsigned int, unsigned long, etc.sizeof(size_t) is an implementation-defined number of bytes so memcpy'ing it or assigning into any integer type other than uintmax_t is a bad idea. I'm not even sure that it is safe to assume that it is of equal size or smaller than uintmax_t.size_t value to a binary file and reading it back into a size_t by another process, on a different machine, or by something compiled with different compiler options can be hazardous to your health.size_t value across a network and trying to receive it using a sizeof(size_t) buffer on the other side is rather unsafe.All of these are standard issues with any other integer type except unsigned char. So size_t is just as portable as any other integer type.