<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
True that:<BR>
<BR>
> (LAST(INTEGER) + 1) = FIRST (INTEGER)<BR><BR>
<BR>
many folks would like to see fail before it gets to the "=".<BR>
<BR>
The dilemna remains though because:<BR>
<BR>
> (LAST(INTEGER) + 1L) = FIRST (INTEGER)<BR><BR>
<BR>
would not fail.<BR><BR>
So, you can either look at it as they produce different values, or one succeeds and one fails.<BR>
Either way people don't like two different expressions doing two different things.<BR>
Again, converting an INTEGER to a LONGINT is one of the simplest things you can do.<BR>
<BR>
There something here about "transitivity" or "replacement":<BR>
<BR>
j2 := VAL(i1, LONGINT) + j3;<BR>
vs.<BR>
j2 := i1 + j3;<BR>
<BR>
pretty clearly have the same meaning.<BR>
The conversion is always trivial and always succeeds.<BR>
Does anyone really find it ambiguous?<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Tue, 12 Jan 2010 03:27:23 +0000<BR>> From: dabenavidesd@yahoo.es<BR>> To: m3devel@elegosoft.com; jay.krell@cornell.edu<BR>> Subject: Re: [M3devel] 64bit file sizes now?<BR>> <BR>> Hi all:<BR>> forgive my ignorance of current discussion and implementation of LONGINT but I read something about arithmetic overflow; I didn't feel was reasonable even if the current implementation doesn't support arithmetic overflow checks, I must say we can't assume this expression: <BR>> (LAST(INTEGER) + 1) = FIRST (INTEGER)<BR>> This sort expression by itself should be catched at compile or run time as an execution error as any CPU would halt in such a case of division by zero, or at least a flag (an exception, etc).<BR>> Nonetheless writing code in CM3 that exploit this restriction would be useless in M3 systems with overflow checking, so I really want to say that at least we can't assume M3 code to do this kind of "assumptions". It other words this is unsafe. I don't how far would people like to have checks on arithmetic expressions, what do you think of creating a compiler option to generate arithmetic overflow check code. <BR>> Please let me know if I'm wrong about this issue on current discussions. <BR>> <BR>> --- El lun, 11/1/10, Jay K <jay.krell@cornell.edu> escribió:<BR>> <BR>> > De: Jay K <jay.krell@cornell.edu><BR>> > Asunto: [M3devel] 64bit file sizes now?<BR>> > Para: "m3devel" <m3devel@elegosoft.com><BR>> > Fecha: lunes, 11 de enero, 2010 22:02<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > So.. LONGINT as I understand will remain roughly as it was,<BR>> > except VAL(expr, INTEGER) is how you convert expr to<BR>> > INTEGER, instead of ORD(expr).<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > And this is already in place.<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > ?<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > So I should go ahead and update File.i3/Status/size and<BR>> > Rd/Wr/Index/Seek/Length to all be LONGINT, "whatever<BR>> > the consequences"? The consequences are roughly the<BR>> > first diff I sent out, with the caveats that I used ORD()<BR>> > instead of VAL(,INTEGER), and a few packages were left to<BR>> > fix. It is mechanical and simple and predictable, just<BR>> > tedious and ugly.<BR>> > Most Rd/Wr users are limited to INTEGER "sizes"<BR>> > anyway, but a few might gain capacity.<BR>> > <BR>> > Classic simple example is the mklib and libdump code, they<BR>> > read the entire file into memory and then deal with that.<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > I can send the diffs ahead of time, but there's really<BR>> > no choices left as to what they'll look like, it is<BR>> > forced by the limited capability of LONGINT.<BR>> > <BR>> > Had they used LONGINT in the first place, of course,<BR>> > there'd be no diff at this time, the ugliness would have<BR>> > been builtin from the start.<BR>> > <BR>> > <BR>> > <BR>> > <BR>> > <BR>> > - Jay<BR>> > <BR>> > <BR>> > <BR>> <BR>> <BR>> <BR> </body>
</html>