<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>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?</div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>Thanks,</div>
<div>Randy Coleburn<br>
<br>
Sent from my iPhone</div>
<div><br>
On Sep 30, 2013, at 12:48 AM, "Jay K" <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<br>
<br>
</div>
<blockquote type="cite">
<div><style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr"> > NUMBER(array) to yield a LONGCARD<br>
<br>
This can't be.<br>
Arrays are in-memory data structures. <br>
INTEGER/CARDINAL are an appropriate type<br>
to hold the size of something fits in memory/address-space.<br>
INTEGER is like C's ptrdiff_t. <br>
CARDINAL is kind of like C's size_t, except it is half range. <br>
Word.T is kind of like C's size_t, except it has no convenient in-fix operators.
<br>
<br>
<br>
Files commonly do not fit in memory/address-space. <br>
So they arguably should have their size stored <br>
in a larger type.<br>
<br>
<br>
I think there is no easy answer here.<br>
<br>
<br>
I would be ok with:<br>
- put it back to INTEGER/CARDINAL <br>
- expose another way new way to get a LONGCARD <br>
<br>
<br>
- Jay<br>
<br>
<br>
<br>
<br>
<div>
<hr id="stopSpelling">
From: <a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a><br>
To: <a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>
Date: Sun, 29 Sep 2013 22:59:35 +0000<br>
Subject: [M3devel] question on File.Status.size<br>
<br>
<style id="ecxowaParaStyle">
.ExternalClass P {
}
</style>
<div style="direction:ltr;font-family:Tahoma;color:#000000;font-size:10pt;">I've been trying to rebuild all my developed software using my newly rebuilt cm3 from the HEAD branch.<br>
<br>
I've run into some new build errors and have a question.<br>
<br>
It seems the type of File.Status.size has been changed to LONGCARD.<br>
<br>
I have some code that now fails to build because of this change.<br>
<br>
I suppose this interface change is an attempt to better deal with files whose size in bytes is larger than MAX(CARDINAL).<br>
<br>
So, for example:<br>
fs := FS.Status(file);<br>
INC(numBytes, fs.size);<br>
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.<br>
<br>
<b>Has the language definition also been updated to allow NUMBER(array) to yield a LONGCARD ?</b><br>
(Interface File uses open arrays)<br>
<br>
In my old language definition, it says that:<br>
<blockquote><a name="idx.43" target="_blank">An</a> open array type declaration has the form:
<br>
<pre> TYPE T = ARRAY OF Element
</pre>
where <tt>Element</tt> is any type. The values of <tt>T</tt> are arrays whose element type is
<tt>Element</tt> and whose length is arbitrary. The index type of an open array is the
<b><tt>INTEGER</tt> subrange </b><tt>[0..n-1]</tt>, where <tt>n</tt> is the length of the array.
</blockquote>
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.<br>
<br>
<b>How does one know in advance if NUMBER(x) is going to yield a CARDINAL or a LONGCARD value, esp. for open arrays?<br>
</b><br>
Thanks,<br>
Randy Coleburn<br>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</body>
</html>