Re: Why is this not a warning?

2016-03-20 Thread jmh530 via Digitalmars-d
On Wednesday, 16 March 2016 at 18:39:36 UTC, Mathias Lang wrote: Sadly, to solve that without imposing much pain on the users, you need a more decent VRP than we currently have, I just read Walter's Dr. Dobbs article on VRP: http://www.drdobbs.com/tools/value-range-propagation/229300211

Re: Why is this not a warning?

2016-03-20 Thread Mathias Lang via Digitalmars-d
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: Please consider the following program, which is a reduced version of a problem I've spent the entire of today trying to debug: import std.stdio; void main() { enum ulong MAX_VAL = 256; long value = -500; if(

Re: Why is this not a warning?

2016-03-19 Thread tsbockman via Digitalmars-d
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: ... People who are marginally familiar with integer promotion will not be surprised to know that the program prints "256". What is surprising to me is that this produced neither error nor warning. The comparable program in

Re: Why is this not a warning?

2016-03-19 Thread jmh530 via Digitalmars-d
On Thursday, 17 March 2016 at 09:13:34 UTC, tsbockman wrote: You could use the `DebugInt` wrapper. It aliases to `SafeInt` in debug and unittest mode, to find problems (many, including the specific one in this thread, are detected at compile time). Then, in release mode, it aliases to the

Re: Why is this not a warning?

2016-03-19 Thread Basile B via Digitalmars-d
On Thursday, 17 March 2016 at 12:35:27 UTC, Basile B wrote: import std.traits; bool safeIntegralCmp(string op, L, R)(auto ref L lhs, auto ref R rhs) if (isIntegral!R && isIntegral!L) { // safe static if (is(Unqual!L == Unqual!R)) { mixin("return lhs" ~ op ~ "rhs;"); }

Re: Why is this not a warning?

2016-03-19 Thread Dominikus Dittes Scherkl via Digitalmars-d
On Thursday, 17 March 2016 at 09:13:34 UTC, tsbockman wrote: On Thursday, 17 March 2016 at 06:55:34 UTC, Shachar Shemesh wrote: On 16/03/16 23:50, tsbockman wrote: On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: ... People who are marginally familiar with integer

Re: Why is this not a warning?

2016-03-19 Thread Uranuz via Digitalmars-d
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: Please consider the following program, which is a reduced version of a problem I've spent the entire of today trying to debug: import std.stdio; void main() { enum ulong MAX_VAL = 256; long value = -500; if(

Re: Why is this not a warning?

2016-03-19 Thread Basile B via Digitalmars-d
On Thursday, 17 March 2016 at 09:59:41 UTC, Dominikus Dittes Scherkl wrote: Or you can use an improved opCmp implementation in the compiler, that only add additional runtime cost, [...] The compiler could statically fix two cases, ALWAYS without runtime cost. I think that FPC does this:

Re: Why is this not a warning?

2016-03-19 Thread jmh530 via Digitalmars-d
On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: People who are marginally familiar with integer promotion will not be surprised to know that the program prints "256". What is surprising to me is that this produced neither error nor warning. Here's a simpler example:

Re: Why is this not a warning?

2016-03-19 Thread tsbockman via Digitalmars-d
On Thursday, 17 March 2016 at 09:59:41 UTC, Dominikus Dittes Scherkl wrote: Or you can use an improved opCmp implementation in the compiler, that only add additional runtime cost, if someone is stupid enough to compare signed with unsigned values - but yield the correct result: I should also

Why is this not a warning?

2016-03-19 Thread Shachar Shemesh via Digitalmars-d
Please consider the following program, which is a reduced version of a problem I've spent the entire of today trying to debug: import std.stdio; void main() { enum ulong MAX_VAL = 256; long value = -500; if( value>MAX_VAL ) value = MAX_VAL; writeln(value); } People

Re: Why is this not a warning?

2016-03-19 Thread Kagamin via Digitalmars-d
https://issues.dlang.org/show_bug.cgi?id=259

Re: Why is this not a warning?

2016-03-18 Thread tsbockman via Digitalmars-d
On Thursday, 17 March 2016 at 06:55:34 UTC, Shachar Shemesh wrote: On 16/03/16 23:50, tsbockman wrote: On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: ... People who are marginally familiar with integer promotion will not be surprised to know that the program prints

Re: Why is this not a warning?

2016-03-18 Thread Shachar Shemesh via Digitalmars-d
On 16/03/16 23:50, tsbockman wrote: On Wednesday, 16 March 2016 at 16:40:49 UTC, Shachar Shemesh wrote: ... People who are marginally familiar with integer promotion will not be surprised to know that the program prints "256". What is surprising to me is that this produced neither error nor

Re: Why is this not a warning?

2016-03-18 Thread tsbockman via Digitalmars-d
On Thursday, 17 March 2016 at 09:59:41 UTC, Dominikus Dittes Scherkl wrote: Or you can use an improved opCmp implementation in the compiler, that only add additional runtime cost, if someone is stupid enough to compare signed with unsigned values - but yield the correct result: For the

Re: Why is this not a warning?

2016-03-18 Thread tsbockman via Digitalmars-d
On Wednesday, 16 March 2016 at 18:39:36 UTC, Mathias Lang wrote: Sadly, to solve that without imposing much pain on the users, you need a more decent VRP than we currently have... Lionello Lunesu did a lot of work both on improving VRP, and on bug 259: