Hacker News Reader

Comment by Dzugaru | Hacker News Reader

This is why I never ever use size_t over int. I’m a newbie C++ programmer tho, wrote less than 10kloc of C++ code, but my both feet are bleeding cause of exactly this.

View on HN

Be careful, int is usually 32-bit even on 64-bit systems. Using int all over is a good way to experience mysterious failures when dealing with chunks of data larger than 2GB, which is definitely a real possibility these days. Consider ssize_t, intptr_t, or int64_t any time you’re not absolutely sure you’ll never exceed 2^31-1.

Int is only 32 bits on 64-bit Windows, that for some reason didn't go along with the times. Every other mainstream 64 bits environment has 64 bits ints, even on ARM.

But it's only guaranteed to be 16 bits anyway, the same guarantee you have for size_t.

I think the point being made is that size_t is guaranteed to be large enough to hold the size of any object. The other integer types don't have this guarantee.

Size_t is guaranteed to hold values up to 65535. That's twice as long as int and much smaller than long.

size_t is guaranteed to hold values large enough to index into any array you can allocate. On a 64-bit system with an allocator that supports allocations larger than 4GB, that means size_t has to be larger than 32 bits. If it's an LLP64 system, size_t will be larger than long. If the value represents an index or size of something in memory, use size_t. Consider ssize_t if you need negative values and are certain you never need the larger half of the size_t range.

That's long, not int. Approximately nobody has 64 bit int.

That's a good approximation :)

Huh? Linux and Darwin both have 32-bit int. I’m sure there are some where it’s 64-bit, but the only one I’m aware of is old Cray systems.

C makes it hard to have anything bigger than 32-bit int. The standard integer types are char, short, int, long, and long long, and if int is 64-but then you’ll lack a standard type for 8, 16, or 32 bit integers, which is inconvenient. Nothing says you have to have those, or that you can’t make some implementation-specific type to fill the gap, but it’s messy.

With C99 I think it's better to use the fixed (or minimum) sized types from stdint.h when my requirements differ from what C guarantees. I prefer to be as explicit as possible in code (when appropriate) so as to to avoid this sort of confusion.

I generally agree. I'm speaking more from the implementor's side: if you do ILP64, then you either won't have one of 8, 16, or 32-bit integers, or you'll have to make some non-standard type to cover the gap. LP64 and LLP64 let you cover all the sizes you typically want with the standard types. That is, I assume, why 32-bit int on 64-bit systems is so common.

The split is LP64 (long is 64 bits, typically Unix) and LLP64 (long long is 64 bits, Windows).

Overflow and underflow on signed types is undefined behavior in C.

You should almost always use unsigned types unless you must use a signed type. And you need to think about these kinds of overflow and underflow cases.

Standard library operations such as length() on a string are defined to return to return a size_type, which is usually going to be an unsigned integer (https://en.cppreference.com/w/cpp/string/basic_string). So, you don't always have the option of avoiding it. You could convert to a signed integer, but that's usually going to be a narrowing conversion, which will introduce different subtle behavior. Unfortunately, in C and C++, there's no silver bullet for avoiding subtleties with integers.

Reply on news.ycombinator.com