<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
"0..LAST(LONGINT)" having varying meaning...like when INTEGER is > 64 bits, then LONGINT=INTEGER, and we anticipate 128 bit INTEGER?<BR>
<BR>
<BR>
See..LONGINT is only useful in this brief period where we still have 32bit INTEGER.<BR>
(Actually it would have been useful long ago.)<BR>
<BR>
<BR>
I really think "long" is a dumb name..<BR>
There should be INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64, and unsigned and signed integers the same size of a pointer, possibly called INT and UINT, or size_t and ptrdiff_t..<BR>
<BR>
<BR>
- Jay<BR><BR> <BR>> Date: Wed, 16 Dec 2009 16:56:55 -0600<BR>> From: rodney_bates@lcwb.coop<BR>> To: m3devel@elegosoft.com<BR>> Subject: Re: [M3devel] Oops, forgot to ask<BR>> <BR>> Tony Hosking wrote:<BR>> > On 16 Dec 2009, at 15:48, Peter Eiserloh wrote:<BR>> ><BR>> > <BR>> >> Hi Gang,<BR>> >><BR>> >> 0 - CARDINALs are an integral type defined by the language<BR>> >> spec to be from 0 (zero) to MAXINT (not MAXCARD). Recently,<BR>> >> a change was made to CM3 to extend the language it recognizes<BR>> >> beyond the original language spec (SPWM3), now CM3 understands<BR>> >> a LONGINT. <BR>> >><BR>> >> Was there a corresponding LONGCARD defined?<BR>> >> <BR>> ><BR>> > No. But you can write:<BR>> ><BR>> > [0L..LAST(LONGINT)]<BR>> ><BR>> > just as<BR>> ><BR>> > CARDINAL=[0..LAST(INTEGER)]<BR>> > <BR>> Actually, the line above was once true, long long ago, when dinosaurs<BR>> roamed unfettered. CARDINAL was changed to be "just like"<BR>> (but not equal to) [0..LAST(INTEGER)]. This would have been<BR>> maybe early 1990s. <BR>> <BR>> It took me years to figure out what this actually meant, and more<BR>> years to figure out why, but I believe I now know. CARDINAL is not an<BR>> equal type to [0..LAST(INTEGER)], but otherwise has all the same<BR>> properties. This makes the two mutually assignable, which is close<BR>> enough to equal to not matter in most contexts. The exact consequences<BR>> follow from other language rules. <BR>> <BR>> The motivation is this: [0..LAST(INTEGER)] on a 32-bit machine is not<BR>> equal to [0..LAST(INTEGER)] on a 64-bit machine (or any combination of<BR>> machines with different values of LAST(INTEGER)), because the numeric<BR>> value of LAST(INTEGER) is part of the expanded type. The one place this<BR>> matters is if you use pickles to transfer data between machines of different<BR>> word sizes. If the type is [0..LAST(INTEGER)], the type signature (a hash<BR>> of the complete, expanded type definition) is different on the two machines,<BR>> and values of or containing this type cannot be transferred. Exact type<BR>> signature matches are used in pickles to find corresponding types when<BR>> reading. <BR>> <BR>> But pickles handle different sized INTEGER values fine, expanding/shortening<BR>> as needed. Being a leaf in a type definition, INTEGER is always the same<BR>> type on any machine. So CARDINAL was changed to be its own unique<BR>> type too, so it would be possible also to transfer CARDINAL values in <BR>> pickles<BR>> between different word sizes. <BR>> <BR>> So, we really should have a LONGCARD, parallel to CARDINAL.<BR>> <BR>> Note that this also affects network objects, which use pickles to transfer<BR>> values of the objects.<BR>> <BR>> <BR>> <BR>> ><BR>> > <BR>> >> Can is use all 64-bits, or is it restricted to 63, like<BR>> >> the CARDINAL is only 31-bits.<BR>> >> <BR>> ><BR>> > 63 bits, since its underlying base type is LONGINT.<BR>> ><BR>> ><BR>> > <BR>> >><BR>> >><BR>> >><BR>> >> +--------------------------------------------------------+<BR>> >> | Peter P. Eiserloh |<BR>> >> +--------------------------------------------------------+<BR>> >><BR>> >><BR>> >><BR>> >> <BR>> ><BR>> ><BR>> > <BR>> <BR> </body>
</html>