Bug or what?

[Marco Leise via Digitalmars-d]

Am Wed, 27 Aug 2014 20:30:08 +0000
schrieb "Phil Lavoie" <maidenphil at hotmail.com>:

> On Wednesday, 27 August 2014 at 20:28:11 UTC, Phil Lavoie wrote:
> > On Wednesday, 27 August 2014 at 20:05:27 UTC, MacAsm wrote:
> >> On Wednesday, 27 August 2014 at 19:51:48 UTC, Phil Lavoie 
> >> wrote:
> >>> Ok so me and one of my colleagues have been working on some 
> >>> code at a distance. We both use dmd as the compiler. I am 
> >>> under Windows, she OSX.
> >>>
> >>> It is not uncommon that she experiences more strictness in 
> >>> the type system than I do. For example, something like this 
> >>> does compile for me, but not for her:
> >>>
> >>> int func(size_t i)
> >>> {
> >>> return i;
> >>> }
> >>>
> >>> It passes my compilation. She gets an error msg about 
> >>> implicit casting of uint to int. I'm just wondering... has 
> >>> anybody else experienced that and what is the expected 
> >>> behavior?
> >>>
> >>> Thanks,
> >>> Phil
> >>
> >> size_t is a typedef to unsigned (check out 
> >> http://dlang.org/type.html). So this warning is correct. I 
> >> don't get this warning too. Maybe it's the type-checking that 
> >> does differ on OSX. Are you using same compiler version and 
> >> flags?
> >
> > Yeah yeah I checked it out and we both use same versions and 
> > everything. Basically, to bit word size coherent I should just 
> > have writtent this instead:
> >
> > ptrdiff_t func(size_t i) {return i;}
> >
> > Though it is still somewhat unsafe, at least it behaves the 
> > same on both our machines.
> >
> > Phil
> 
> Note that the compiler behaves the same, the code, not 
> necessarily.

In my opinion this should always give you a compiler warning,
as it is not portable to 64-bit:

uint func(size_t i) {return i;}

But that has been discussed and reported to death already :D

I'm also somewhat pedantic about assigning unsigned to signed
types and vice versa. Most of the times I'd rather change the
code so that I can keep using e.g. unsigned absolute values
instead of differences.

-- 
Marco