Strange calculation problem

2009-08-25 Thread JPF
I've hit a strange problem somewhere in my code and I narowed it down to the following testcase: -- module test; import tango.io.Stdout; const ulong SIZE_IN_B = (1024 * 1024 * 1024 * 2); /*should be 2147483648*/ void main() { Stdout.formatln("{0}", SIZE_IN_B); /*but is

Re: Strange calculation problem

2009-08-25 Thread Lars T. Kyllingstad
JPF wrote: I've hit a strange problem somewhere in my code and I narowed it down to the following testcase: -- module test; import tango.io.Stdout; const ulong SIZE_IN_B = (1024 * 1024 * 1024 * 2); /*should be 2147483648*/ void main() { Stdout.formatln("{0}", SIZE_IN_

Re: Strange calculation problem

2009-08-25 Thread bearophile
Lars T. Kyllingstad: > I think the compiler should be smart enough to figure this out for > itself, but until that happens you can work around it by suffixing at > least one of the integer literals with LU, so the compiler interprets > the entire expression as an ulong: To make this fix happen

Re: Strange calculation problem

2009-08-25 Thread Steven Schveighoffer
On Tue, 25 Aug 2009 05:35:31 -0400, JPF wrote: I've hit a strange problem somewhere in my code and I narowed it down to the following testcase: -- module test; import tango.io.Stdout; const ulong SIZE_IN_B = (1024 * 1024 * 1024 * 2); /*should be 2147483648*/ void main()

Re: Strange calculation problem

2009-08-25 Thread grauzone
bearophile wrote: Lars T. Kyllingstad: I think the compiler should be smart enough to figure this out for itself, but until that happens you can work around it by suffixing at least one of the integer literals with LU, so the compiler interprets the entire expression as an ulong: To make thi

Re: Strange calculation problem

2009-08-25 Thread JPF
Thanks for the answers. (I think I don't have to say specifying the literal did work ;-)) Actually I should have known that, but somehow I just didn't think of it.

Re: Strange calculation problem

2009-08-25 Thread Tom S
bearophile wrote: Lars T. Kyllingstad: I think the compiler should be smart enough to figure this out for itself, but until that happens you can work around it by suffixing at least one of the integer literals with LU, so the compiler interprets the entire expression as an ulong: To make thi

Re: Strange calculation problem

2009-08-26 Thread bearophile
Steven Schveighoffer: > This is not a bug, and will probably not be changed (it's been this way > since C). It is impossible for the compiler to know whether you wanted > sign extension or not, as some code depends on sign extension. I'd like overflow errors bot at compile and run-time, to av

Re: Strange calculation problem

2009-10-20 Thread Pelle M�nsson
You find it well defined and expected that the compiler translate 1024*1024*1024*2 to -1*1024*1024*1024*2? Why would you not want it to actually become, you know, what you write? Since it is a ulong that it should fit in, why would you expect the compiler to follow signed integer overflow rules?