[M3devel] question on File.Status.size

[Tony Hosking]

Why would size of a file necessarily be CARDINAL if that is not sufficient for the OS.
For example, if off_t is not the same as CARDINAL then we have problems supporting POSIX files.
Hence the need for LONGCARD.
And I don’t understand why the size of a file should relate to NUMBER unless you are assuming that you can allocate an array to hold an entire file’s contents.

Antony Hosking | Associate Professor | Computer Science | Purdue University
305 N. University Street | West Lafayette | IN 47907 | USA
Mobile +1 765 427 5484





On Sep 30, 2013, at 1:38 PM, "Coleburn, Randy" <rcolebur at SCIRES.COM> wrote:

> Whether it is signed or not, to me it only makes sense that both the size of a file and NUMBER(x) are always semantically a CARDINAL type, i.e., >= 0.
> --Randy Coleburn
>  
> From: Tony Hosking [mailto:hosking at cs.purdue.edu] 
> Sent: Monday, September 30, 2013 11:46 AM
> To: Coleburn, Randy
> Cc: Jay K; m3devel
> Subject: EXT:Re: [M3devel] question on File.Status.size
>  
> Indeed, I wonder if it should be Long.T instead of LONGCARD, because I am uneasy with the assumption that the representation might not change.
> (I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.)
> Now, on the other hand, POSIX specifies file sizes to be off_t, which is signed, whereas Long.T is meant to be thought of as unsigned.
>  
> So, should M3 adopt the POSIX spec that a file size is a signed value?  In which case I suppose LONGCARD makes sense.
>  
> On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" <rcolebur at SCIRES.COM> wrote:
> 
> 
> I haven't looked at the various underlying implementations of File.T but have they all been adjusted to deal with FS.Status.size now being a LONGCARD while the internal buffers are limited to arrays whose length can be no more than INTEGER?
>  
> If so, then I guess I need to adjust my code to deal with bigger files (even though my code won't actually use bigger files). 
>  
> I'm not complaining. I just want to make sure this interface change has been well thought out and implemented and is going to persist before I embark on changes to code that has been in production for years. 
>  
> Thanks,
> Randy Coleburn
> 
> Sent from my iPhone
> 
> On Sep 30, 2013, at 12:48 AM, "Jay K" <jay.krell at cornell.edu> wrote:
> 
>  > NUMBER(array) to yield a LONGCARD
> 
>   This can't be.
>   Arrays are in-memory data structures. 
>   INTEGER/CARDINAL are an appropriate type
>   to hold the size of something fits in memory/address-space.
>   INTEGER is like C's ptrdiff_t. 
>   CARDINAL is kind of like C's size_t, except it is half range. 
>   Word.T is kind of like C's size_t, except it has no convenient in-fix operators. 
> 
> 
>   Files commonly do not fit in memory/address-space. 
>   So they arguably should have their size stored 
>   in a larger type.
> 
> 
>  I think there is no easy answer here.
> 
> 
>  I would be ok with:
>    - put it back to INTEGER/CARDINAL 
>    - expose another way new way to get a LONGCARD 
>  
> 
>  - Jay
> 
> 
> 
> 
> From: rcolebur at SCIRES.COM
> To: m3devel at elegosoft.com
> Date: Sun, 29 Sep 2013 22:59:35 +0000
> Subject: [M3devel] question on File.Status.size
> 
> I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch.
> 
> I've run into some new build errors and have a question.
> 
> It seems the type of File.Status.size has been changed to LONGCARD.
> 
> I have some code that now fails to build because of this change.
> 
> I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL).
> 
> So, for example:
>    fs := FS.Status(file);
>    INC(numBytes, fs.size);
> no longer works if numBytes is defined as a CARDINAL.  Of course, I can change its type to be LONGCARD, but there will be a ripple effect throughout the code.
> 
> Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ?
> (Interface File uses open arrays)
> 
> In my old language definition, it says that:
> An open array type declaration has the form:
>     TYPE T = ARRAY OF Element
> where Element is any type. The values of T are arrays whose element type is Element and whose length is arbitrary. The index type of an open array is the INTEGER subrange [0..n-1], where n is the length of the array.
> In the past NUMBER(x) always yielded a CARDINAL, not a LONGCARD.  So, if this has changed, I'll need to do some more updates across my code base.
> 
> How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays?
> 
> Thanks,
> Randy Coleburn
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20130930/809c6d41/attachment-0002.html>