Michiel Helvensteijn wrote:
Walter Bright wrote:
In other words, every bug in DMD is really a feature of the language.
Until you fix it. That kind of permanent instability may be part of the
reason people have been so negative around here lately.
I don't agree with that characterization. Bugs get reported to bugzilla,
and get fixed in a regular cycle.
Sure they do. But if it's really true that the DMD implementation *is* the D
language specification, any bug in DMD would also be part of that
specification. And as the compiler changes, so does the spec. It's the
danger of that approach.
Looking at the kinds of issues reported in bugzilla makes it pretty
plain that D users well understand the difference between a bug and a
problem with the specification. I don't believe there is any danger
there. Nobody is going to mistake a compiler crash, for example, as
specified behavior.
I will file those corrections.
Thank you, I look forward to it.
Issue 3165, Issue 3166.
Thank you.
By the way, what kind of integer division *does* D use?
To be frank, it is what the x86 DIV instruction does.
After a quick Google search, it would seem DIV is the x86 "unsigned divide"
instruction. Are you sure you aren't using IDIV ("signed divide") for
negative operands? If not, you'd actually be interpreting 2's complement
signed ints as unsigned ints. (And surely such a thing would have been
noticed before now?)
If there's any question about it, you can do a quick test and check what
the compiler generates with obj2asm. If it wasn't doing things
correctly, you bet people would have noticed by now. A divide that
doesn't work is going to be very, very obvious.
But I agree that
the modulus should be defined, regardless of whether that makes it less
efficient on some machines.
Good. Make sure that your divide operation and your modulo operation are
consistent. The following identity should hold:
if a / n = q
and a % n = r
a = q*n + r
