Hi all: The best idea I thing, tough I'm not an expert is to use static methods at the low level of the m3 system, let's say the gcc backend. This is not something really easy, but it's doable. I know for Open64 project http://www.open64.net, see "Implement a static program analysis tool based on Open64 compiler". It's something  I found interesting in that area. SRC Modula-3 version 3.3 does not do arithmetic overflow or underflow checking, see the manual reference attached in the mail (see section 1.11.1). But what about pm3 or cm3? The other way it's also more traditional with static tools in the source code of the compiled program (well it's more tedious for most of us, it's using a specification language for a checker). Someone has checked open 64 as a possible backend of cm3? Thanks "Rodney M. Bates" <rodney.bates@wichita.edu> escribió:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left:

 5px; padding-left: 5px;"> <br><br>Jay wrote:<br>>>>it'd be nice imho for    the language or m3core to also build-in UINTEGER, INT8, INT16,<br>>>>INT32, INT64, UINT8, UINT16, UINT32, UINT64, just so folks wouldn't   <br>>>>have to provide them themselves. (CARDINAL I don't think is what I   <br>>>>want.)<br>>>>Add them somewhere in m3core?<br>>>>MODULE Integers; ?<br>>><br>>>Such things may be convenient for programmers, but are left out of the<br>>>language because the specification must not become too long, I think.<br>>>I'd opt for library extensions in this case.<br>> <br>> <br>> Good enough.<br>> Except I'm not sure about UINTEGER..like..why is CARDINAL only half range?<br>> I'd have to dig in..NOT now..<br>> <br><br>I've been through this in Modula-2.  There, CARDINAL is a whole, unsigned<br>range.  Unfortunately, this created a linguistic and portability nightmare.<br>It

 was worse because I don't think the original Modula-2 definition completely<br>specified things like assignability between the two, operators on mixtures<br>of the two, implied conversions, etc.  I know different implementations were<br>different to the point it was difficult even to write code that would compile<br>on them all.<br><br>Maybe there is a cleaner way to have two distinct types, one signed, one<br>unsigned, and both full range, but it would at least be tricky.  The Modula-3<br>way is found in Word.  Word.T is the same type as INTEGER, but the operations<br>in Word (e.g. Word.Times) apply unsigned interpretation to the bits of the<br>same-typed value.  This avoids a lot of problems.  So for full range, unsigned,<br>values, use Word (and probably, to show your intent to readers, declare<br>variables as Word.T rather than INTEGER, even though it is the same type).<br><br>As for CARDINAL in Modula-3, it was originally exactly [0..LAST(INTEGER)].<br>This was

 changed later to say it is "just like" [0..LAST(INTEGER)].<br>It was years before I fully understood this.  I once posted a question on<br>the M3 newsgroup about it and gave up waiting for an answer.  Then I read<br>the compiler code and found what it means, literally, is that CARDINAL is a<br>different type from [0..LAST(INTEGER)], but the two have all the same legal operations.<br>This distinction seldom matters, because it is almost always assignability and<br>not type equality that is relevant.  Which didn't help explain why.<br><br>Then there was an answer to my question saying that the change in the definition<br>of CARDINAL was to support Pickles, but this still left me in the dark.<br><br>Finally, while working on Pickles, it dawned on me that, without the change,<br>it would not be possible for Pickles to change the size of a CARDINAL between<br>32 & 64 bits.  The type [0..LAST(INTEGER)] (or any other similar subrange) is<br>a different type if LAST(INTEGER)

 has a different value.  CARDINAL, in contrast,<br>can change range between platforms and still be the same type.<br><br>Moral: Don't pickle anything whose type contains values like LAST(INTEGER) that<br>differ from platform to platform.<br><br>> <br>>>Yes, IIRC there are no checks on integer overflow; this is an<br>>>implementation flaw. How would you provide this? Add generation of<br>>>checks on every integer operation?<br>> <br>> <br>> Well, it's a no-win situation.<br>> The check would bloat the code.<br>> Even function calls would bloat and slow.<br>> Probably function calls.<br><br>I happen to be extremely conservative on the value of detecting runtime errors,<br>even at efficiency cost.  I heard some horror stories in the early years of my<br>career about programs that had been in use for years and whose output had been<br>used to plan the expenditure of huge amounts of money, then were accidentally<br>found to be producing

 wrong (though not obviously so) output, that would have<br>been caught by running with runtime checks enabled.<br><br>In any case, big time cost increases (e.g. double) associated with a few operations<br>very often amortize over the whole program's run time to only 1% or 2%.<br><br>> <br>> And then hopefully optimize them some.<br>> For example:<br>> FOR i := 0 TO n DO<br>>    ...<br>> END;<br>> <br>> Check up front then n isn't negative, and then no checking is needed for the incrementing of n to overflow.<br><br>Overflow in compiler-generated arithmetic is a little different than in arithmetic explicitly<br>coded by the programmer.  In this example,  the language specifically exempts the compiler from<br>worrying about this.  2.3.16, last sentence:  "If the upper bound of the loop is LAST(INTEGER),<br>it should be rewritten as a WHILE loop to avoid overflow."<br><br>As for other optimizations, the language specifies the semantics, so a compiler

 is free to do<br>anything that complies with this.<br><br>> <br>> Similarly,<br>> FOR i := 0 TO n BY 2 DO<br>> <br>>    ...<br>> <br>> END;<br>> <br>> or whatever is the syntax, check if the start/end are divisible by the increment and the start is less than the end, and then no overflow check needed<br><br>-- <br>-------------------------------------------------------------<br>Rodney M. Bates, retired assistant professor<br>Dept. of Computer Science, Wichita State University<br>Wichita, KS 67260-0083<br>316-978-3922<br>rodney.bates@wichita.edu<br></blockquote><br><p> 

      <hr size=1><br><font face="Verdana" size="-2">Tu correo también desde el móvil.<br><a href="http://es.mobile.yahoo.com">Descárgate gratis Yahoo! Go</a>.<br></font>