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

[Jonathan M Davis]

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