Hacker News Reader

Comment by rwmj | Hacker News Reader

Some of this comes about from the choice of LP64 (32 bit ints on 64 bit platforms[0]). There seems no sensible reason why ints are 32 bit on a 64 bit platform, it only introduces inefficiency[1] and these kinds of problems.

The one argument I've seen is there would be no 32 bit type (since the next smallest integer, ie. short, would be 16 bit), but a compiler could easily have a __builtin_int32 mapped to C99 standard int32_t etc.

In C code that we write, we have a rule that every use of plain 'int' must be justified - it's a "code smell". Most places where 'int' is used should be replaced with 'size_t' (if used as an index to an array), or a C99 int32_t etc.

[0] https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_m...

[1] https://gist.github.com/rygorous/e0f055bfb74e3d5f0af20690759...

View on HN

> There seems no sensible reason why ints are 32 bit on a 64 bit platform, it only introduces inefficiency[1]

I don't think that is a fair summary of your link at all.

First of all, the conclusion of that link's analysis is that there is no performance penalty in this case, because the compiler exploits undefined behavior to eliminate any penalty it might otherwise have caused.

Secondly, 32-bit instructions on x64 are smaller than 64-bit instructions. For example "inc eax" is a 2-byte instruction, but "inc rax" is 3 bytes. This is because 64-bit instructions need a REX prefix.

Also, as others have mentioned, there is the issue of RAM usage.

I'm not arguing that 32-bit integers are superior overall. I'm just saying that 64-bit integers aren't strictly better in terms of efficiency. For cases that will never need more than 32 bits, a 32-bit integer is probably better.

>There seems no sensible reason why ints are 32 bit on a 64 bit platform

The reasoning I have always heard is to keep RAM usage constant. If you have a standarts complient C program that uses primarily int as datatype, then with 64 bit ints the 64 bit version of the program uses twice as much memory as the 32 bit version of the same program.

I'm not sure I would call it a great reason, but 32 bit ints may have been the pragmatic thing to do.

I completely disagree (except with the size_t bit - I agree with that). In my view, it's usages of int32_t and similar that should be justified: why you do you need exactly 32 bits and 2s complement representation - why does at least 32 bits and unspecific representation not suffice?

> why does at least 32 bits and unspecific representation not suffice?

Because that doesn't help you. Static reasoning becomes harder. Dynamic checks (pretending the exact size is unknown) are possible but .. the exact size is statically known (just not to the programmer). It is a waste.

The sentiment is right, but the solution is metaprogramming, not unhelpfully underspecified types.

I didn't say that every use of 'int' should be replaced by 'int32_t'. In fact most uses are replaced with 'size_t' because you're counting something and should be worrying about overflow/wraparound.

Also I didn't say that you should never use 'int'. Yesterday I had to use 'int' because the sscanf %n pattern requires it, ironically an example of exactly what I'm talking about -- it won't be able to handle strings longer than ~2^31 bytes. But in this case the string comes from a place where we know it cannot exceed this limit, so we're OK.

Depends on your application I would say, if you build a database you want it to be able to store more automatically when hardware gets better. If you store physical measurements from sensors you know for sure that this sensor can only give values within a certain range, there you want to ensure you have the range required and it's also redundant to use a larger variable. I would still prefer int_least32 over just int though to be more explicit.

> There seems no sensible reason why ints are 32 bit on a 64 bit platform

Try storing a few billion of them, they're half the size.

> In C code that we write, we have a rule that every use of plain 'int' must be justified - it's a "code smell"

Current MISRA C requires this.

You could also pack three 20-bit numbers into a 64-bit word, if you needed it. Then again, the C family languages are kind of weird about that.

Unicode code points are 21 bits long. I wonder if something out there stores strings by packing 3 code points per uint64_t.

Maybe, but almost everything outside the basic multilingual plane is so infrequently used that it's a waste of space to use a fixed-width format.

But I could see it being a useful replacement for UTF-32... If you need to be able to calculate code points in constant time, and you don't mind wasting one bit out of every 64. Self synchronizing, constant time code point count from buffer size, and close to as space efficient as UTF-16, but with none of the surrogate mess.

Well, 32 bit ints dramatically simplified the porting of some 32-bit software to 64-bit since it didn't cause large arrays of integers to suddenly double in size.

not to mention better wire protocol and driver compatibility without a rewrite.

Reply on news.ycombinator.com