Comment #0 by bearophile_hugs — 2010-10-16T10:08:54Z
It's better to design the D language to minimize the amount of changes (and pitfalls) needed to port 32 bit code to 64 bit.
On 64 bit systems a size_t is 64 bit, while int/uint are 32 bit wide still. In D code I've seen this, that compiles with no errors:
int i = array.length;
But on 64 bit systems this code throws away half of the bits of the length, and I think the compiler doesn't allow that assignment without a cast.
So in that assignment size_t=>int I suggest to raise a compile error on 32 bit systems too, so porting code from 32 to 64 bit doesn't require a change in that line of code.
(Beside this one, there are few other situations where D2 may be changed to avoid some troubles caused by porting 32 bit code to 64 bit code. I'd like such other situations too to be addressed.)
Comment #1 by bugzilla — 2010-10-25T01:08:31Z
Code that compiles on 32 bits but fails to compile on 64 bits with an appropriate message is not much of a problem. Making size_t its own type rather than an alias brings along a whole host of other problems.
Besides, it is perfectly legitimate to use an int to index an array on 64 bits.
Also, it is D best practice to rewrite:
int i = array.length;
as:
auto i = array.length;
unless one *specifically* requires an int.
Comment #2 by dfj1esp02 — 2010-10-25T21:36:05Z
This is not always possible. We also have fields and function parameters.
ps I manage this bug by defining shorter aliases - intp and uintp.
Comment #3 by Marco.Leise — 2013-06-08T00:45:10Z
I reopened this bug to extend the discussion a bit. This is a real issue in writing portable code. I've tried to use a D library written on 32-bit that wasn't usable because it mixed size_t and uint all over the place. Likewise I tend to forget that file sized are ulong and store them in size_t variables, making my 64-bit code not portable to 32-bit.
I think the compiler should at least warn about every implicit conversion between size_t and (u)int/(u)long. The size_t -> ulong and uint -> size_t cases being the only ones that should be silently allowed for consistency with the other integral type conversions.
What are the difficulties in the implementation or the semantics?
Have any warnings been implemented recently that make this enhancement request obsolete?
> Besides, it is perfectly legitimate to use an int to index an array on 64 bits.
That is besides the point of this enhancement request. When you have a uint already from whatever source and your array is known to be < 2^32 it is of course perfectly legitimate to do that.
But when you have a dynamic array and ask it for it's length you should be reminded to store the result in a size_t or a ulong.
And the reverse example (which breaks coming from 64-bit to 32-bit):
struct S { size_t size; }
S s;
s.size = file.size();
Here the compiler should warn me that ulong != size_t as well.
Comment #5 by bearophile_hugs — 2013-06-11T04:26:13Z
(In reply to comment #4)
> To back our point up a bit, here are some bug tickets that show up on a search
> for size_t:
>
> ...
The D compiler here has enough static information to avoid future troubles in porting D code written on a 32 bit system to 64 bit systems. It's a good idea to use such information as much as possible. D has a static type system, so let's actually use it.
Comment #7 by pro.mathias.lang — 2020-09-06T22:11:00Z
I'm going to re-close this. Walter has opposed this already and so am I.
Any "solution" would likely trigger a cascade of false positives, which is a pretty good indication that the problem is not actually being addressed.
We can't magically make people write portable code. There will always be false negatives, if only for the fact system bindings will be different (and might not use `size_t`). And we don't even want to: Why should we force a person coding only for his hobby project to write code that is portable to an architecture one does not care about ?
Sure, integer conversions need improvements, but having a strongly typed `size_t` (especially given we removed `typedef`) is not the way.