[M3devel] what to do about file sizes being 32bits?

[Tony Hosking]

On 8 Jan 2010, at 13:54, hendrik at topoi.pooq.com wrote:

> On Fri, Jan 08, 2010 at 11:44:48AM +0100, Olaf Wagner wrote:
>> 
>> Just my opinion of course. I don't really understand why you are so
>> drastically opposing LONGINT suddenly. Probably I haven't been able to
>> follow some of the arguments.
> 
> I could understand opposition to LONGINT if it were based on it being a 
> kludge stuck in to quickly patch a problem while we spend time thinking 
> about the real, elegant solution.  And having two types like INTEGER and 
> LONGINT without one being a subrange of the other seems like a kludge to 
> me, however necessary it also appears.

It really is kind of a kludge invented just for large files.

> But let me ask a question.  Is there ever any need for a Modula 3 
> compiler to implement a type like 0..1024 as more than 16 bits?  Even if 
> INTEGER is 32 bits?

[0..1024] has memory representation of 16 bits.  What's the point of the question?  Values of [0..1024] are INTEGER and operations on them are INTEGER typed.

> (I might have asked "more than 12 bits" in the above question, but 
> modern 23-bit machines may very well have 16-bit operations but not 
> 12-bit operations.)
> 
> -- hendrik
> 
> P.S.  As far as I know, I don't think the C standard ever specifies that 
> arithmetic operations on its file offset type (Is it offset_t?  I 
> forget.) have any relation whatsoever to actual file position?  As far 
> as I know, it could be a count of the number of bytes to read to reach 
> that position, or it could consist of cylinder, track, and sector 
> numbers, or it could even be encrypted.  Fie on the C implementor that 
> does any of these things, though.

Right, so this argues in favor of a cleaner abstraction of file offsets rather than LONGINT.