On 11/24/13 3:38 AM, Iain Buclaw wrote:
> https://github.com/D-Programming-Language/druntime/pull/663

There's only one effective way to keep things portable, and that's continuous testing on multiple platforms that exercise the various differences.  The only way to get that is to have druntime and phobos pulls continuously tested against dmd and gdc and ldc as a condition of merging.

Relying on reviewers who have little to no experience maintaining those non-x86 platforms is doomed to failure.  It doesn't surprise me in the least that non-x86-portability issues arise without being caught by the current committers and reviewers.

On 25/11/13 09:52, Jonathan M Davis wrote:
> 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.

You're quite right -- I was just thinking about underlying stuff along the lines of what Iain was pointing out for real, not "user-land" cases like this.

To be honest, I assumed that anyone with any experience or common sense would understand stuff like the example you've described, and not write such code. But that's probably very very naive ... :-)

The size_t case I rather like to think of is:

     size_t m = ...;
     size_t p = 1 << m;    // should this be 1U, 1UL ... ?

On Monday, November 25, 2013 10:40:11 Joseph Rushton Wakeling wrote:
> On 25/11/13 09:52, Jonathan M Davis wrote:
> > 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.
> 
> You're quite right -- I was just thinking about underlying stuff along the lines of what Iain was pointing out for real, not "user-land" cases like this.
> 
> To be honest, I assumed that anyone with any experience or common sense would understand stuff like the example you've described, and not write such code. But that's probably very very naive ... :-)

Many people seem to just use int everywhere, and a lot of D code failed to compile when 64-bit support was finally added. It's probably less a problem now then it used to be, but it's still not all that uncommon to see code examples that get it wrong (particularly from Windows users, where using 64-bit is more of a pain). It happens all the time in C/C++ as well, but C/C++ will allow the conversion implicitly, so for better or worse, it works as long as the numbers aren't too large.

> The size_t case I rather like to think of is:
> 
>       size_t m = ...;
>       size_t p = 1 << m;    // should this be 1U, 1UL ... ?

I'd be _very_ suspicious of any bitshifts that aren't done on types with a fixed size.

- Jonathan M Davis

On 25/11/13 11:34, Jonathan M Davis wrote:
> Many people seem to just use int everywhere, and a lot of D code failed to
> compile when 64-bit support was finally added.

Ack :-(

One thing that slightly rings alarm bells for me with D is that, because the integral sizes are fixed, people use short/ushort, int/uint, long/ulong etc. for explicit 16-, 32- or 64-bit integrals.  By contrast I do rather like the explicitness of something like uint64_t as a means of saying, "Yes, at this point in the code I really, really want a precisely 64-bit unsigned integral type."

IIRC we do have them in D code, but isn't their use frowned on?

>> The size_t case I rather like to think of is:
>>
>>        size_t m = ...;
>>        size_t p = 1 << m;    // should this be 1U, 1UL ... ?
>
> I'd be _very_ suspicious of any bitshifts that aren't done on types with a
> fixed size.

This was in fact exactly how I learned about how to handle 32- vs 64-bit issues.  I had some simulation code suddenly start generating different values after I installed a 64-bit OS.

My 32-bit code had run fine because the wraparound of the 1 << m bitshift brought it back around to where it was supposed to be (I was shifting it by about 30 or 31), whereas on 64-bit it was (surprise surprise) landing in the wrong place.

I doubt that I can say that I've _never_ written unportable code since then, but ever since, I've always tried to address such size-related issues.

>>int len = arr.length;

 That isn't an error in D?

 Every C++ code base I've worked in enables max warnings/warnings as errors, this would never compile--

 Does it at least trigger a warning?

On Monday, 25 November 2013 at 11:15:00 UTC, froglegs wrote:
>>>int len = arr.length;
>
>  That isn't an error in D?
>
>  Every C++ code base I've worked in enables max warnings/warnings as errors, this would never compile--
>
>  Does it at least trigger a warning?

Because `arr.length` returns a `size_t` value i would imagine this compiles fine on a 32bit OS but throws an error on a 64bit OS. I think this demonstrates precisely the problem.

On Monday, November 25, 2013 12:14:59 froglegs wrote:
> >>int len = arr.length;
> 
>   That isn't an error in D?
> 
>   Every C++ code base I've worked in enables max warnings/warnings
> as errors, this would never compile--
> 
>   Does it at least trigger a warning?

No. It's not a warning, and dmd is not big on warnings (and IMHO warnings you should be abolished, but that's another discussion). Regardless, given how size_t is implemented, the compiler doesn't really even know that it exists anyway. It's aliased to uint on 32-bit systems and ulong on 64-bit systems, so every place that size_t is used, it gets replaced with the type that it's aliased to, and the compiler forgets that it was ever anything else - the same thing happens with all aliases.

So, on 32-bit systems, size_t is uint and

int len = arr.length;

works just fine, because uint implicitly converts to int. Whereas on 64-bit systems, size_t is ulong, and ulong does _not_ implicitly convert to int, so you get an error.

So, on 32-bit systems, it compiles just fine, and 64-bit systems you get an error, but no systems will give you a warning.

- Jonathan M Davis

On Monday, 25 November 2013 at 09:05:14 UTC, Brad Roberts wrote:
> On 11/24/13 3:38 AM, Iain Buclaw wrote:
>> https://github.com/D-Programming-Language/druntime/pull/663
>
> There's only one effective way to keep things portable, and that's continuous testing on multiple platforms that exercise the various differences.  The only way to get that is to have druntime and phobos pulls continuously tested against dmd and gdc and ldc as a condition of merging.

The gold standard: Every pull request (or every commit) should be tested with DMD/LDC/GDC on x86/amd64/arm with Linux/Win/OSX. That is already 27 variants. Actually there should probably be more like with/without SSE.

On 25/11/13 13:28, qznc wrote:
> The gold standard: Every pull request (or every commit) should be tested with
> DMD/LDC/GDC on x86/amd64/arm with Linux/Win/OSX. That is already 27 variants.
> Actually there should probably be more like with/without SSE.

You have a challenge that (AFAIK, as things are) patches to the frontend can't be automatically guaranteed to apply cleanly to GDC and LDC as well as DMD.  And given that druntime and phobos patches can depend on frontend features, there's some difficulty in being able to automatically test patches to any part of the D core code against all the backends.

On 2013-11-25 13:28, qznc wrote:

> The gold standard: Every pull request (or every commit) should be tested
> with DMD/LDC/GDC on x86/amd64/arm with Linux/Win/OSX. That is already 27
> variants. Actually there should probably be more like with/without SSE.

And FreeBSD.

-- 
/Jacob Carlborg