[M3devel] question on File.Status.size
rcolebur at SCIRES.COM
Mon Sep 30 15:49:43 CEST 2013
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.
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
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);
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?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the M3devel