Re: A little story
On 25/06/12 14:24, bearophile wrote: Dmitry Olshansky: Except for the fact, that someone has to implement it. I am not seeing one of the posts of this thread. So I'll answer here. The good thing regarding the run-time overflow integral tests is that they are already implemented and available as efficient compiler intrinsics in both GCC and LLVM back-ends. It's just a matter of using them (and introducing the compiler switch and some kind of pragma syntax). Bye, bearophile Bearophile, haven't you ever read that paper on integer overflow, which you keep posting to the newsgroup??? It clearly demonstrates that it is NOT POSSIBLE to implement integer overflow checking in a C-family language. Valid, correct, code which depends on integer overflow is very, very common (when overflow occurs, it's more likely to be correct, than incorrect). I don't think you could do it without introducing a no-overflow integer type. The compiler just doesn't have enough information.
Re: A little story
Don Clugston: Bearophile, haven't you ever read that paper on integer overflow, which you keep posting to the newsgroup??? I have read it time ago, but it seems not having run-time overflow tests is not an option for certain programming endeavors of mine. This is why I have partially switched back to FreePascal for those. It clearly demonstrates that it is NOT POSSIBLE to implement integer overflow checking in a C-family language. Clarke says something nice: When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong. http://embed.cs.utah.edu/ioc/ Valid, correct, code which depends on integer overflow is very, very common (when overflow occurs, it's more likely to be correct, than incorrect). I was discussing about an annotation to disable it locally where the programmer wants such overflows (like using wrap-around semantics to avoid testing for negative values. I have done this myself some times). I am not interested in taking a quite optimized 80_000 lines long C program and switching on the run-time integral overflow tests on it all, all at once. This is probably going to fail, as the paper says. Smaller D programs written from zero with run-time overflow tests are one example of what I was thinking about. I don't think you could do it without introducing a no-overflow integer type. The compiler just doesn't have enough information. This solution sounds acceptable for part of my purposes, thanks to D alias syntax. But I don't know if it's enough. Bye, bearophile
Re: A little story
Tobias Pankrath: Maybe you should post this to the main newsgroup. I don't know if the main newsgroup is the right place. I would prefer a switch that does this per scope, i.e: I think both a compiler switch for the compilation unit, and a scope pragma to enable/disable locally, are useful. Bye, bearophile
Re: A little story
On 25-Jun-12 14:01, bearophile wrote: Tobias Pankrath: Maybe you should post this to the main newsgroup. I don't know if the main newsgroup is the right place. I would prefer a switch that does this per scope, i.e: I think both a compiler switch for the compilation unit, and a scope pragma to enable/disable locally, are useful. While I think that if you seek anything other then plain fixnum you'd better make wrapper type adding nessary overflow checks. It should be almost as fast as plain fixnum if it's not then it's a bug/feature request for optimizer/inliner. -- Dmitry Olshansky
Re: A little story
On Monday, 25 June 2012 at 10:08:03 UTC, Dmitry Olshansky wrote: On 25-Jun-12 14:01, bearophile wrote: Tobias Pankrath: Maybe you should post this to the main newsgroup. I don't know if the main newsgroup is the right place. I would prefer a switch that does this per scope, i.e: I think both a compiler switch for the compilation unit, and a scope pragma to enable/disable locally, are useful. While I think that if you seek anything other then plain fixnum you'd better make wrapper type adding nessary overflow checks. It should be almost as fast as plain fixnum if it's not then it's a bug/feature request for optimizer/inliner. If you have already written code, it may be cumbersome to port it to a wrapper type, if the only thing you want to test is, that it does not have overflows. You can't just do alias MyWrapper!int int; can you? They are a common source of bugs, detecting those should be made easy. I do see this as automatic DbC for build-ins and can not see any counter argument that would not equally apply to the current DbC state. Except for the fact, that someone has to implement it.
Re: A little story
On 25-Jun-12 15:21, Tobias Pankrath wrote: On Monday, 25 June 2012 at 10:08:03 UTC, Dmitry Olshansky wrote: On 25-Jun-12 14:01, bearophile wrote: Tobias Pankrath: Maybe you should post this to the main newsgroup. I don't know if the main newsgroup is the right place. I would prefer a switch that does this per scope, i.e: I think both a compiler switch for the compilation unit, and a scope pragma to enable/disable locally, are useful. While I think that if you seek anything other then plain fixnum you'd better make wrapper type adding nessary overflow checks. It should be almost as fast as plain fixnum if it's not then it's a bug/feature request for optimizer/inliner. If you have already written code, it may be cumbersome to port it to a wrapper type, if the only thing you want to test is, that it does not have overflows. You can't just do alias MyWrapper!int int; can you? I surely can do s/int/Integer/. They are a common source of bugs, detecting those should be made easy. I do see this as automatic DbC for build-ins and can not see any counter argument that would not equally apply to the current DbC state. Except for the fact, that someone has to implement it. -- Dmitry Olshansky
Re: A little story
Dmitry Olshansky: Except for the fact, that someone has to implement it. I am not seeing one of the posts of this thread. So I'll answer here. The good thing regarding the run-time overflow integral tests is that they are already implemented and available as efficient compiler intrinsics in both GCC and LLVM back-ends. It's just a matter of using them (and introducing the compiler switch and some kind of pragma syntax). Bye, bearophile
Re: A little story
On Sun, 24 Jun 2012 23:52:35 +0200 bearophile bearophileh...@lycos.com wrote: - Python language is not fit because it's too much slow and because in certain cases I prefer a little stronger static type safety, that's useful to not waste time debugging the usage of intricate data structures. Have you tried to use Cython which gives some 'static type safety' and it is often used to speed up critical parts of the Python program. I'd really curios to see results with Cython... Sincerely, Gour -- Abandoning all attachment to the results of his activities, ever satisfied and independent, he performs no fruitive action, although engaged in all kinds of undertakings. http://atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 signature.asc Description: PGP signature
Re: A little story
Am 25.06.2012 14:56, schrieb Gour: On Sun, 24 Jun 2012 23:52:35 +0200 bearophile bearophileh...@lycos.com wrote: - Python language is not fit because it's too much slow and because in certain cases I prefer a little stronger static type safety, that's useful to not waste time debugging the usage of intricate data structures. Have you tried to use Cython which gives some 'static type safety' and it is often used to speed up critical parts of the Python program. I'd really curios to see results with Cython... Sincerely, Gour I would like to see the result with PyPy, Cython is mostly not faster than CPython.
Re: A little story
On 24/06/12 23:52, bearophile wrote: And D is too much unsafe for such kind of programs, because integral numbers can silently overflow. Is there any GMP port for D ? Jerome
Re: A little story
Jerome BENOIT: Is there any GMP port for D ? Jerome I don't know. (But GMP is NOT a solution to the problems shown in that story). Bye, bearophile
Re: A little story
On 25/06/12 01:51, bearophile wrote: Jerome BENOIT: Is there any GMP port for D ? Jerome I don't know. (But GMP is NOT a solution to the problems shown in that story). How come as ``integral numbers (will not be) overflow'' ? Bye, bearophile
Re: A little story
Jerome BENOIT: How come as ``integral numbers (will not be) overflow'' ? Multiprecision numbers allocate on the heap when they become large (or they always allocate on the heap). This has a significant performance impact. There are many situations where Multiprecision numbers are handy, but there are many other cases where you want to keep most of the performance (or memory use, or struct layouts, and type signatures, and more) of the normal machine fixnums. In this case compilation switches to enable/disable run-time overflow errors are useful. Bye, bearophile
Re: A little story
Thanks a lot for the explanation. Jerome On 25/06/12 02:54, bearophile wrote: Jerome BENOIT: How come as ``integral numbers (will not be) overflow'' ? Multiprecision numbers allocate on the heap when they become large (or they always allocate on the heap). This has a significant performance impact. There are many situations where Multiprecision numbers are handy, but there are many other cases where you want to keep most of the performance (or memory use, or struct layouts, and type signatures, and more) of the normal machine fixnums. In this case compilation switches to enable/disable run-time overflow errors are useful. Bye, bearophile
