On Sunday, 24 November 2013 at 22:38:15 UTC, Jonathan M Davis wrote:
> On Sunday, November 24, 2013 17:15:25 Johannes Pfau wrote:
>> We have one type in D which has a different size depending on platform
>> and it's the number one source for platform-specific problems...
>
> 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.

Isn't size_t unsigned and ptrdiff_t signed?

>
> But it is true that a large portion of our platform-specific problems stem from
> types that vary in size.
>
> - Jonathan M Davis

On Monday, November 25, 2013 00:34:31 ponce wrote:
> On Sunday, 24 November 2013 at 22:38:15 UTC, 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
> > there's also ptrdiff_t, which is effectively an unsigned size_t.
> 
> Just to correct things, size_t is unsigned, ptrdiff_t is the signed one.

Correct. I mistyped. Sorry about that.

- Jonathan M Davis

On Monday, November 25, 2013 01:50:47 Craig Dillabaugh wrote:
> Isn't size_t unsigned and ptrdiff_t signed?

Yes. I mistyped.

- Jonathan M Davis

On Sunday, 24 November 2013 at 15:34:37 UTC, Shammah Chancellor wrote:
> On 2013-11-24 11:38:25 +0000, Iain Buclaw said:
>
>> https://github.com/D-Programming-Language/druntime/pull/663
>
> A link to pages of a pull extension for CTFE hashes.   Care to clarify?

You only need to look as far as the FloatTraits template to then shake
your head in misery. ;-)

On Sunday, 24 November 2013 at 22:38:15 UTC, Jonathan M Davis wrote:
>
> But it is true that a large portion of our platform-specific problems stem from
> types that vary in size.
>

Size *and* format. ie: big/little endian, 80/96/128bit reals, etc...

My biggest problem with stuff like this (see link in original post) is that after so much combined effort getting things working across multiple architectures - just take a look at any pull for version MIPS, PPC, PPC64, SPARC, ARM, etc... or my pull for implementing std.math for almost all (double-double reals the main one missing), IEEE real types - someone goes ahead and breaks support for all these targets and no one thinks or lifts an eyebrow over it.

Library maintainers need to stop writing code with the assumption that their code is only going to be used with dmd and x86, and they should have stopped doing it 6 months ago.

On Monday, 25 November 2013 at 07:43:38 UTC, Iain Buclaw wrote:
>
> Library maintainers need to stop writing code with the assumption that their code is only going to be used with dmd and x86, and they should have stopped doing it 6 months ago.

Aiming 'library maintainers' at the druntime/phobos folk.  Because third party libraries are not a concern yet. ;)

On Monday, November 25, 2013 08:43:37 Iain Buclaw wrote:
> On Sunday, 24 November 2013 at 22:38:15 UTC, Jonathan M Davis
> 
> wrote:
> > But it is true that a large portion of our platform-specific
> > problems stem from
> > types that vary in size.
> 
> Size *and* format. ie: big/little endian, 80/96/128bit reals, etc...
> 
> My biggest problem with stuff like this (see link in original post) is that after so much combined effort getting things working across multiple architectures - just take a look at any pull for version MIPS, PPC, PPC64, SPARC, ARM, etc... or my pull for implementing std.math for almost all (double-double reals the main one missing), IEEE real types - someone goes ahead and breaks support for all these targets and no one thinks or lifts an eyebrow over it.
> 
> Library maintainers need to stop writing code with the assumption that their code is only going to be used with dmd and x86, and they should have stopped doing it 6 months ago.

In a lot of cases, I  expect that folks just forget. In others, they don't realize that what they're doing won't work on other targets. I'm aware of some of the issues involved with all of that, but I fully expect that I'm not aware of them all, and I expect that it's the same with many of the other developers. And since the autotester only targets dmd and x86(_64), non- x86(_64) breakage isn't caught when it occurs - though it's my understanding at this point, that the integration between gdc or ldc and the front-end is not smooth enough to be able to simply rebuild them when the front-end gets updated, which would likely be required to integrate them into the autotester.

I don't know how to solve the main issue other than educating people better. Personally, I don't get involved with druntime pulls all that often, because I often don't feel qualified to do so (and I should get involved with Phobos pulls more than I do, but I'm busy enough these days that that's hard - though hopefully that will be improving relatively soon).

I expect that there's enough work to get there that it'll be a while before we do, but if we could reach the point where gdc and ldc could be built as part of the autotester (especially if that can be done with multiple architectures), that would go a long way towards fixing the breakage problems.

- Jonathan M Davis

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?

On 25/11/13 09:00, Jonathan M Davis wrote:
> I don't know how to solve the main issue other than educating people better.

Is it possible to define an artificial test situation where real is defined to be 64-bit, even though it's technically being compiled on x86(_64) hardware which supports 80-bit floats?

That ought to catch any cases where someone assumes that real is 80-bit, no?

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