[M3devel] A "radical" proposal: drop LONGINT

John Polstra jdp at polstra.com
Wed Jan 6 22:06:00 CET 2010


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     
> 



More information about the M3devel mailing list