[M3devel] A "radical" proposal: drop LONGINT

[Jay K]

We still have a bug where merely browsing to a directory with a file > 4GB with the Trestle GUI raises an unhandled exception.
Ideally LONGINT or [0..16_7FFFFFFFFFFFFFFF or higher] would be the type for file sizes everywhere.
It is currently INTEGER and changing it to LONGINT breaks stuff. I'll try the subrange..maybe that'll compile...
I think I proposed changing the type to "double" but nobody including me is super keen on that.
Double does have an interesting property of offering far more range than a 32bit integer on all systems going way back...
 (53bits typically of precision within a 64bit double)

 - Jay


> Date: Wed, 6 Jan 2010 13:06:00 -0800
> From: jdp at polstra.com
> To: hosking at cs.purdue.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] A "radical" proposal:  drop LONGINT
> 
> File sizes and seek offsets (among other things) are 64 bits even on 
> 32-bit machines, and files these days are often larger than 4GB.  In 
> many applications it is necessary to do arithmetic on such values. 
> Also, the fact that Modula-3 traps integer overflows causes trouble when 
> only 32 bits are used for file offsets.  I had to put an ugly 
> work-around into CVSup to avoid an integer overflow fault caused by more 
> than 4GB being sent on a TCP connection.
> 
> John
> 
> Tony Hosking wrote:
> > What do you need those 64-bit types for on 32-bit machines?  On 32-bit 
> > machines INTEGER would still be 32-bit.
> > 
> > On 6 Jan 2010, at 01:12, Jay K wrote:
> > 
> >>
> >> Can I still have:
> >> TYPE INT64 = BITS 64 FOR [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> or
> >> TYPE INT64 = [16_8000000000000000..16_7FFFFFFFFFFFFFFF];
> >> ? defined in an interface, not in the language?
> >>
> >>
> >> If so, probably ok.
> >>
> >>
> >> (And can I also somehow get:
> >> TYPE UINT32 = BITS 32 FOR [0..16_FFFFFFFF];
> >> TYPE UINT64 = BITS 64 FOR [0..16_FFFFFFFFFFFFFFFF];
> >> or
> >> TYPE UINT32 = [0..16_FFFFFFFF];
> >> TYPE UINT64 = [0..16_FFFFFFFFFFFFFFFF];
> >> ?
> >> )
> >>
> >>
> >> Even on 32 bit machines?
> >>
> >>
> >> I know there is interface Word.
> >>
> >>
> >> And then, what is the difference between:
> >>
> >>
> >> on 32bit:
> >>   INTEGER vs. [16_80000000..16_7FFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFF]
> >>
> >>
> >> on 64bit:
> >>   INTEGER vs. [16_8000000000000000..16_7FFFFFFFFFFFFFFF]
> >>   CARDINAL vs. [0..16_7FFFFFFFFFFFFFFF]
> >>
> >>
> >> Any at all?
> >> Just that array sizes are cardinal?
> >>
> >>
> >> I don't know much about the language issues, but dealing with 64bit 
> >> integers in 32bit Modula-3 ought to be about as easy and efficient as 
> >> dealing with them in C and C++ I think. Hm..and why? Well..file sizes 
> >> should be represented as 64bit integers, though they aren't yet..it 
> >> seems to be a significant interface breaking change..though maybe 
> >> range types aren't where LONGINT would be? I'll have to try that..
> >>
> >>
> >> - Jay
> >>
> >>
> >> ________________________________
> >>> From: hosking at cs.purdue.edu <mailto:hosking at cs.purdue.edu>
> >>> Date: Tue, 5 Jan 2010 21:59:42 -0500
> >>> To: m3devel at elegosoft.com <mailto:m3devel at elegosoft.com>
> >>> Subject: [M3devel] A "radical" proposal: drop LONGINT
> >>>
> >>>
> >>>
> >>> Now that Jay has carefully refactored all the C-dependent code, I'd 
> >>> like to pose the following question. What say we clean things up, 
> >>> revert to the original clean language definition, and eliminate 
> >>> LONGINT? It was only ever there for compatibility with C headers 
> >>> anyway, and these have all now been nicely abstracted away. The only 
> >>> remaining uses of LONGINT are in defining Modula-3 alternatives for C 
> >>> structs. These can be rewritten to something other than LONGINT.
> >>>
> >>>
> >>> Antony Hosking | Associate Professor | Computer Science | Purdue 
> >>> University
> >>> 305 N. University Street | West Lafayette | IN 47907 | USA
> >>> Office +1 765 494 6001 | Mobile +1 765 427 5484     
> > 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20100107/7dd1b511/attachment-0002.html>