<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
--></style>
</head>
<body class='hmmessage'>
We still have a bug where merely browsing to a directory with a file > 4GB with the Trestle GUI raises an unhandled exception.<br>Ideally LONGINT or [0..16_7FFFFFFFFFFFFFFF or higher] would be the type for file sizes everywhere.<br>It is currently INTEGER and changing it to LONGINT breaks stuff. I'll try the subrange..maybe that'll compile...<br>I think I proposed changing the type to "double" but nobody including me is super keen on that.<br>Double does have an interesting property of offering far more range than a 32bit integer on all systems going way back...<br> (53bits typically of precision within a 64bit double)<br><br> - Jay<br><br><br>> Date: Wed, 6 Jan 2010 13:06:00 -0800<br>> From: jdp@polstra.com<br>> To: hosking@cs.purdue.edu<br>> CC: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] A "radical" proposal: drop LONGINT<br>> <br>> File sizes and seek offsets (among other things) are 64 bits even on <br>> 32-bit machines, and files these days are often larger than 4GB. In <br>> many applications it is necessary to do arithmetic on such values. <br>> Also, the fact that Modula-3 traps integer overflows causes trouble when <br>> only 32 bits are used for file offsets. I had to put an ugly <br>> work-around into CVSup to avoid an integer overflow fault caused by more <br>> than 4GB being sent on a TCP connection.<br>> <br>> John<br>> <br>> Tony Hosking wrote:<br>> > What do you need those 64-bit types for on 32-bit machines? On 32-bit <br>> > machines INTEGER would still be 32-bit.<br>> > <br>> > On 6 Jan 2010, at 01:12, Jay K wrote:<br>> > <br>> >><br>> >> Can I still have:<br>> >> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];<br>> >> or<br>> >> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];<br>> >> ? defined in an interface, not in the language?<br>> >><br>> >><br>> >> If so, probably ok.<br>> >><br>> >><br>> >> (And can I also somehow get:<br>> >> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];<br>> >> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];<br>> >> or<br>> >> TYPE UINT32 = [0..16_FFFFFFFF];<br>> >> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];<br>> >> ?<br>> >> )<br>> >><br>> >><br>> >> Even on 32 bit machines?<br>> >><br>> >><br>> >> I know there is interface Word.<br>> >><br>> >><br>> >> And then, what is the difference between:<br>> >><br>> >><br>> >> on 32bit:<br>> >> INTEGER vs. [16_80000000..16_7FFFFFFF]<br>> >> CARDINAL vs. [0..16_7FFFFFFF]<br>> >><br>> >><br>> >> on 64bit:<br>> >> INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]<br>> >> CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]<br>> >><br>> >><br>> >> Any at all?<br>> >> Just that array sizes are cardinal?<br>> >><br>> >><br>> >> I don't know much about the language issues, but dealing with 64bit <br>> >> integers in 32bit Modula-3 ought to be about as easy and efficient as <br>> >> dealing with them in C and C++ I think. Hm..and why? Well..file sizes <br>> >> should be represented as 64bit integers, though they aren't yet..it <br>> >> seems to be a significant interface breaking change..though maybe <br>> >> range types aren't where LONGINT would be? I'll have to try that..<br>> >><br>> >><br>> >> - Jay<br>> >><br>> >><br>> >> ________________________________<br>> >>> From: hosking@cs.purdue.edu <mailto:hosking@cs.purdue.edu><br>> >>> Date: Tue, 5 Jan 2010 21:59:42 -0500<br>> >>> To: m3devel@elegosoft.com <mailto:m3devel@elegosoft.com><br>> >>> Subject: [M3devel] A "radical" proposal: drop LONGINT<br>> >>><br>> >>><br>> >>><br>> >>> Now that Jay has carefully refactored all the C-dependent code, I'd <br>> >>> like to pose the following question. What say we clean things up, <br>> >>> revert to the original clean language definition, and eliminate <br>> >>> LONGINT? It was only ever there for compatibility with C headers <br>> >>> anyway, and these have all now been nicely abstracted away. The only <br>> >>> remaining uses of LONGINT are in defining Modula-3 alternatives for C <br>> >>> structs. These can be rewritten to something other than LONGINT.<br>> >>><br>> >>><br>> >>> Antony Hosking | Associate Professor | Computer Science | Purdue <br>> >>> University<br>> >>> 305 N. University Street | West Lafayette | IN 47907 | USA<br>> >>> Office +1 765 494 6001 | Mobile +1 765 427 5484 <br>> > <br> </body>
</html>