Why is it that no one writes with portability in mind in druntime?

[Jonathan M Davis]

On Monday, November 25, 2013 09:25:46 Joseph Rushton Wakeling wrote:
> On 24/11/13 23:38, Jonathan M Davis wrote:
> > No. We have several types which vary in size. In addition to real, there's
> > also size_t (which should be being used in almost all D programs, whereas
> > real is used in far fewer), and there's also ptrdiff_t, which is
> > effectively an unsigned size_t. And of course, all of the pointer types
> > vary in size, as do the c_* types from druntime when you have to interact
> > with C (though those aren't part of the language - or even just treated
> > as part of the language as size_t and ptrdiff_t are, since they're
> > defined in object_.d). So, even if almost all of D's numeric types don't
> > vary in size, there are some that do.
> But ... am I not right that size_t and ptrdiff_t are essentially just
> defined as aliases to either ulong and long (for 64-bit) or uint and int
> (32-bit) code?  So don't you essentially get support for them "for free"
> just by supporting 32- and 64-bit integral types?  Or are there still
> problems that arise?

Yes, they're aliases, but you have to worry about them. Take this code for 
instance.

int len = arr.length;

That code will compile as 32-bit, but it will _not_ compile as 64-bit, because 
length is size_t, which on 32-bit systems happens to be uint, which implicitly 
converts to int, whereas on 64-bit systems, it's ulong, which does _not_ 
implicitly convert to it.

If you want to write D code that compiles on both 32-bit and 64-bit systems, 
you need to be cognizant of size_t and use it rather than int, uint, long, 
ulong, or any of the other integral types when the types involved are actually 
supposed to be size_t or ptrdiff_t. This is actually the type difference that's 
probably the _most_ likely to bite your average D programmer, not real, since 
at this point, most D programs won't ever be compiled on anything other than 
x86(_64), but many of them _will_ be compiled as both 32-bit and 64-bit 
depending on who compiles them and where they compile them.

As we do more with ARM and other platforms, issues with real and possibly othe 
system-specific stuff will become more prevalent, but at the moment, they're 
mostly future problems rather than current ones. The major exception is 
druntime and Phobos (especially druntime) as work is currently being done to 
make those work on other platforms, and work is currently being done on gdc 
and ldc to support those other platforms in the compiler.

- Jonathan M Davis