[M3devel] question on File.Status.size

Mon Sep 30 21:58:05 CEST 2013

Sorry for my lack of precision in what I wrote earlier.

The point I was trying to make earlier is that the result of NUMBER(), and the size of a file, both are semantically non-negative.  Whether that value is stored as a CARDINAL or a LONGCARD (or INTEGER vs LONGINT, even though the value should always be non-negative) is a matter of the range needed.

As for the relation between the two wrt files, I was simply noting that the File and FS INTERFACEs in the past dealt with FS.Status.size and NUMBER() both having the same range (with respect to the open arrays passed thru the INTERFACES).

Now that FS.Status.size has a greater range (namely, LONGCARD), client code that previously dealt with the smaller range has to be updated.

For example, if I'm counting bytes read, I now have a potentially larger number LONGCARD vs CARDINAL to deal with, or if I'm allocating buffers to hold data being read/written, these buffers now have to deal with potentially much greater amount of data, thereby also needing new mechanisms to deal with this much larger data in an efficient way.

Thanks,
Randy Coleburn

From: Tony Hosking [mailto:hosking at cs.purdue.edu]
Sent: Monday, September 30, 2013 2:26 PM
To: Coleburn, Randy
Cc: m3devel
Subject: EXT:Re: [M3devel] question on File.Status.size

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<mailto: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<http://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<mailto: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<mailto: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<mailto:rcolebur at SCIRES.COM>
To: m3devel at elegosoft.com<mailto: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/a34ceb89/attachment-0002.html>