<table cellspacing='0' cellpadding='0' border='0' background='none' style='font-family:arial;font-size:10pt;color:rgb(51, 51, 51);background-color:rgb(255, 255, 255);width:100%;'><tr><td valign='top' style='font: inherit;'>Dear Jay and developers:<br>>What is the status and chance of a 32 bit integer with the range
>0..0xFFFFFFFF and of a 64 bit integer type with range 0 ..
>0xFFFFFFFFFFFFFFFF?<br>I guess you meant like a LONGCARD, I think it was a proposal of native 64 integer language update with recent LONGINT add,  but as I understood it was no accepted (maybe it was not  needed). Did you mean UNSIGNED like a  LONGCARD?<br>There is a Sweden site about the comparison you want to make of C++ types and Modula-3 built-in types (as I understand you want to figure out), maybe this can give you an idea of others thoughts:<br><a href="http://translate.google.com.co/translate?u=http%3A%2F%2Fwww.nada.kth.se%2Fdatorer%2Fhaften%2Fmodula2c%2B%2B%2Fnode9.html&sl=sv&tl=en&hl=es&ie=UTF-8">http://translate.google.com.co/translate?u=http%3A%2F%2Fwww.nada.kth.se%2Fdatorer%2Fhaften%2Fmodula2c%2B%2B%2Fnode9.html&sl=sv&tl=en&hl=es&ie=UTF-8</a><br><br>Also you can check this opinion based on comparison with Modula-2 too:<br><a
 href="http://catless.ncl.ac.uk/Risks/18.60.html#subj7.1">http://catless.ncl.ac.uk/Risks/18.60.html#subj7.1</a><br>Also the m3devel list from 2006. And all the others about 64 native proposal of Rodney Bates and others:<br><a href="http://mailarchive.elegosoft.com/Zope/m3/m3devel/archive/2006/2006-09/1157492987000/index_html?fullMode=1#1158164046000">http://mailarchive.elegosoft.com/Zope/m3/m3devel/archive/2006/2006-09/1157492987000/index_html?fullMode=1#1158164046000</a><br>I would vote to keep simplicity even in the mapping of C types to Modula-3 types, does exist any matrix like the translated web of the url above in the documentation of cm3 to help in the implementations of mapping types?<br>Thanks<br>---<b>2/6/08, Jay <i><jayk123@hotmail.com></i></b> wrote:<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;">De: Jay <jayk123@hotmail.com><br>Asunto: [M3devel] unsigned integers?<br>Para:
 "m3devel@elegosoft.com" <m3devel@elegosoft.com><br>Fecha: lunes, 2 junio, 2008 4:07<br><br><div id="yiv1585025748">

<style>
#yiv1585025748 .hmmessage P
{
margin:0px;padding:0px;}
#yiv1585025748  .hmmessage
{
FONT-SIZE:10pt;FONT-FAMILY:Tahoma;}
</style>
What is the status and chance of a 32 bit integer with the range 0..0xFFFFFFFF and of a 64 bit integer type with range 0 .. 0xFFFFFFFFFFFFFFFF?<br>
 <br>
 <br>
Already available?<br>
Impossible to provide?<br>Only available in unsafe modules?<br>Only available with restricted operations in safe modules, and more operations in unsafe modules?<br>
 <br>
 <br>
Specifically, I think looping from 0 to N is safe -- no overflow.<br>
Subtracting a CARDINAL from an "UNSIGNED" is safe -- cannot overflow.<br>
Adding "UNSIGNED" to "UNSIGNED" is not safe -- can overflow.<br>
Adding or subtracting an INTEGER to "UNSIGNED" is not safe.<br>
Subtracting "UNSIGNED" from "UNSIGNED" is not safe -- can overflow.<br>Comparing UNSIGNED to UNSIGNED for any of =, <, >, !=, is safe.<br>
Comparing UNSIGNED to CARDINAL or INTEGER is safe, but must be done carefully.<br>
  Specifically, UNSIGNED > LAST(CARDINAL) is not equal to any CARDINAL or UNSIGNED.<br>The unsafe operations above could be runtime checked perhaps.<br>
  I guess that's a different larger point/dilemna -- when to allow potentially unsafe operations but with runtime checks vs. the compiler just disallowing them entirely. e.g. adding an integer to an integer is not even safe, but checked maybe at runtime (ok, at least assignment to subrange types is checked). Yes, I know I know, the runtime checks on at least many integer operations is yet lacking.<br>
 <br>
Is there any, um, value in such a type?<br>
Is it just me blindly trying to cast Modula-3 as C (yes), but there's no actual value (uncertain)?<br><br>
 <br>
Btw, I agree there's no point in this type in representing file sizes or offsets. They should be at least 63 bit integers. One bit doesn't buy much for file sizes. It might be something for address spaces though?<br>
 <br>
It bugs me to define types like uintptr_t = CARDINAL or uintptr_t = INTEGER. It seems quite wrong.<br>
Perhaps the unsigned types larger than 16 bits just should not be defined in Cstdint. ??<br>
But there is already Ctypes.unsigned_int, unsigned_long_long, whose underlying type I think is signed, but which convention says you just don't do signed operations on, but which the compiler doesn't enforce, right?<br>
 <br>
You know, maybe Word.T should not be INTEGER but this mythological UNSIGNED/UINT??????<br>
 <br>
 - Jay<br> 
</div></blockquote></td></tr></table><br>






      <hr size=1><br><font face="Verdana" size="-2">Enviado desde <a href="http://us.rd.yahoo.com/mailuk/taglines/isp/control/*http://us.rd.yahoo.com/evt=52431/*http://es.docs.yahoo.com/mail/overview/index.html">Correo Yahoo!</a><br>La bandeja de entrada más inteligente.<br></font>