Is there a place where it lists the specific specs which, as this promotion, are that error prone?

On 07/03/2008, Lionello Lunesu <lionello@lunesu.remove.com> wrote:
> Found it:
>
>  http://erdani.org/d-implicit-conversions.pdf

I tried downloading that (unsuccessfully). However, it seems to me that we don't need a diagram. The rule can be easily expressed purely in logic.

It is safe to implicitly convert from type T to type U, if and only if both of the following two rules apply:

(1) There exists no value x of type T for which
    cast(T) cast(U) x != x

(2) There exists no value x of type T, and no type V, for which
    cast(V) x != cast(V) cast(U) x

Finding a single counterexample to either of those rules is sufficient
to prove a conversion unsafe. For example, one cannot safely
implicitly cast an int to a short, because rule (1) is violated (e.g.
with counterexample x == 0x10000). Likewise, one cannot safely
implicitly cast a uint to an int, because rule (2) is violated (e.g.
with counterexample x == 0xFFFFFFFF and V == long)

Well, that blows C integer promotion rules out of the window! :-)

Oskar Linde wrote:
> Regan Heath wrote:
>> Hey,
>>
>> [DMD 2.010, windows]
>>
>> So.. was doing a bit of simple D coding and got some really odd behaviour, namely this code creates a 4gb (4,294,975,895 bytes) file on my disk!
>>
>> My question is, is this a bug or am I doing something stupid?
> 
> Congratulations, you found another stupid integer promotion rule bug. Those have been a personal gripe for me. Hopefully we can one day fix this horrible design mistake from C.
> 
> The problem is that:
> 
> uint l = 1;
> long c = -l;
> 
> yields c == 4294967295
> 
> wohoo... (Did I mention that I hate those?)
> 
> The error lies in BufferedStream.flush()
> 
> BufferedStream has a uint bufferSourcePos and does:
> 
>       if (bufferSourcePos != 0 && seekable) {
>     // move actual file pointer to front of buffer
>     streamPos = s.seek(-bufferSourcePos, SeekPos.Current);
> 
> and since seeks first argument is a long, it gets a value close to 4GB.

When the file ended up that close to 4gb each time I did suspect an signed/unsigned bug.  Did anyone make a bug report or should I do so now?

Regan