From rodney.bates at gmx.com Tue May 24 18:29:55 2022 From: rodney.bates at gmx.com (Rodney Bates) Date: Tue, 24 May 2022 11:29:55 -0500 Subject: [M3devel] Fwd: [modula3/cm3] The definition of the FOR loop is prone to integer overflow (Issue #1027) In-Reply-To: References: Message-ID: -------- Forwarded Message -------- Subject: Re: [modula3/cm3] The definition of the FOR loop is prone to integer overflow (Issue #1027) Date: Mon, 23 May 2022 12:47:20 -0500 From: Rodney Bates Reply-To: rbates at acm.org To: modula3/cm3 , Norayr Chilingarian , modula3/cm3 CC: Subscribed On 5/23/22 07:37, Norayr Chilingarian wrote: > > i am sorry that i ask without knowing, but does the compiler check (at compile time of course) if the variable used for the looping potentially can overflow? > > let's say we have i: INTEGER; l: LONGINT; > This ..............^ declaration of i is irrelevant, because the FOR loop is an inner scope and declares its own meaning of i. > > would this generate a compile time error? > > |FOR i := 0 to l DO| |Yes, but for a reason possibly different from what you may mean. This is statically illegal because first and last must have the same base type (which is the type this inner i will be given.) INTEGER and LONGINT are distinct base types and are not mutually assignable, to prevent a cascade of questions about the sizes of intermediate arithmetic and results in expressions. There are no implicit type conversions in Modula-3, although assignability provides something roughly equivalent in specific cases. This is unlike CHAR and WIDECHAR, which, though different base types, are mutually assignable without trouble, because there are no arithmetic operations producing results of either type. But you could write FOR i := 0L TO l DO ... and the only overflow questions would be when Last is at one of the very ends of LONGINT, as discussed in Roland Illig's article referenced in his recent post. See 2.3.16, 2nd paragraph, not counting the line of sample code. | > |... END | > > ? > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you are subscribed to this thread.Message ID: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvm at tut.by Tue May 24 20:40:41 2022 From: vvm at tut.by (vvm at tut.by) Date: Tue, 24 May 2022 21:40:41 +0300 Subject: [M3devel] Fwd: [modula3/cm3] The definition of the FOR loop is prone to integer overflow (Issue #1027) In-Reply-To: References:

Message-ID: <602491653417520@mail.yandex.by> An HTML attachment was scrubbed... URL: From rodney.bates at gmx.com Fri May 27 16:39:51 2022 From: rodney.bates at gmx.com (Rodney Bates) Date: Fri, 27 May 2022 09:39:51 -0500 Subject: [M3devel] [modula3/cm3] The definition of the FOR loop is prone to integer overflow (Issue #1027) In-Reply-To: References: Message-ID: <95cc2679-cbe6-2561-2cc1-5c6dc60ffa5b@gmx.com> I like this idea.? When I can find some time, I plan to implement this rewrite in the front end. However, I think I will keep the infinite loop behavior when step=0. Although it seems quite far-fetched, there is a risk of undermining some peculiar existing code that depends on this.? Many is the time I thought some coding pattern was too bizarre to ever actually exist in real-world code (not counting test cases, hack attempts, etc.), only to be proven wrong. I always wrestle with how much optimization to do in the front end. But I plan to do the optimizations of cases where some subset of the loop parameters are constant in the front end.? I imagine llvm folks, at least, would say "leave that to the back end", but there are four back ends, some with many optimization options, some of which sometimes one needs to disable for various unrelated reasons. In contrast, I see The ends-of-range changes as pretty much pure improvements. On 5/22/22 14:02, Roland Illig wrote: > > The Modula-3 FOR statement is defined such that using it with very large or very small integers can result in unexpected overflow errors, which could terminate the program. This makes the FOR loop unnecessarily hard to use in safe and reliable programs. > > Details: modula-3-for-loop.pdf > > ? > Reply to this email directly, view it on GitHub , or unsubscribe . > You are receiving this because you are subscribed to this thread.Message ID: > -------------- next part -------------- An HTML attachment was scrubbed... URL: