[Issue 259] Comparing signed to unsigned does not generate an error (page 3)

https://issues.dlang.org/show_bug.cgi?id=259 Issue 259 depends on issue 9960, which changed state. Issue 9960 Summary: Show warnings/deprecations during template instantiation https://issues.dlang.org/show_bug.cgi?id=9960 What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution|--- |FIXED --

https://issues.dlang.org/show_bug.cgi?id=259 Walter Bright <bugzilla@digitalmars.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bugzilla@digitalmars.com Severity|critical |enhancement --

https://issues.dlang.org/show_bug.cgi?id=259 Manuel König <manuelk89@gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |manuelk89@gmx.net --- Comment #69 from Manuel König <manuelk89@gmx.net> --- I hit this 15 years old bug again, and now feel very insecure about the correctness of all integer comparisons in all my code. At least a warning about signed-unsigned comparison would be great, doing the mathematically correct fast & safe integer promotions would be even better. Not sure how to deal with the slower comparisons like long-unsigned that have no direct assembly comparison instruction, maybe just produce an error message. --

https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #70 from Basile-z <b2.temp@gmx.com> --- The promotion trick works unless both operand are 64 bits (and considering that cent/ucent are not a thing yet) but that would be a progress. For long cmp ulong a warning could be emitted. This topic should make its come back on the news group. Even if the current behavior is layered on C semantics that does not mean that it could not change. Following C is not a sacrosant rule. --

https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #71 from thomas.bockman@gmail.com --- (In reply to Manuel König from comment #69) > Not sure how to deal with the slower comparisons like long-unsigned that have no direct assembly comparison instruction, maybe just produce an error message. Speed is not the issue. The performance cost of a correct signed-unsigned comparison is almost nothing (less than the cost of a single branch mispredict, I believe), and in those very rare cases where the tiny speed boost of doing the comparison incorrectly is really worth it, it is trivial to cast one of the operands to the type of the other. The real problem is that the current strange behaviour of mixed comparisons is occasionally deliberately used in correct code. D must not be updated in a way that silently breaks all that pre-existing correct code. Hence, a warning (or at least, a *long* deprecation period) is the only good option for D2. Introducing such a warning without drowning people in false positives is surprisingly complicated, and is currently stalled waiting for a chain of compiler changes to be completed: https://github.com/dlang/dmd/pull/12311 https://github.com/dlang/dmd/pull/5229 https://github.com/dlang/dmd/pull/1913 --

https://issues.dlang.org/show_bug.cgi?id=259 --- Comment #72 from Stewart Gordon <smjg@iname.com> --- (In reply to thomas.bockman from comment #71) > The real problem is that the current strange behaviour of mixed comparisons is occasionally deliberately used in correct code. D must not be updated in a way that silently breaks all that pre-existing correct code. Hence, a warning (or at least, a *long* deprecation period) is the only good option for D2. I don't understand. How can code that the spec explicitly forbids possibly be correct? --

June 21, 2021

[Issue 259] Comparing signed to unsigned does not generate an error

Posted by thomas.bockman@gmail.com

Permalink

thomas.bockman@gmail.com

Permalink

https://issues.dlang.org/show_bug.cgi?id=259

--- Comment #73 from thomas.bockman@gmail.com ---
(In reply to Stewart Gordon from comment #72)
> I don't understand.  How can code that the spec explicitly forbids possibly be correct?

Normal programmers, who are not language lawyers, generally consider code to be correct if it reliably does what it is intended to do, in the way it is intended to do it.

They do not know or care what the language spec says, and they assume the compiler can be trusted to enforce such simple rules as "mixed signed-unsigned comparisons are forbidden", if necessary.

And, this is a perfectly rational approach, since both the compiler and the spec are complex, change over time, and sometimes contradict each other. Where there is a conflict, a programmer must satisfy the compiler in order to get work done, while the spec is important only in theory.

Regardless of what the spec says, the de-facto semantics of the D language are that mixed signed-unsigned integer comparisons in D use integer promotion, like other mixed operations.

That can certainly be changed, but the compiler needs to point out code that needs to be updated for the new semantics via warnings, deprecations, or errors.

People need to be able to write code and then move on with their lives, and must not be forced to memorize the language spec and manually review all of the code they have ever written in D every time a new version of the compiler or spec comes out, to avoid silent breakage.

--

https://issues.dlang.org/show_bug.cgi?id=259 Iain Buclaw <ibuclaw@gdcproject.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P2 |P4 --

Forums