<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">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.<div>(I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.)</div><div>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.</div><div><br></div><div>So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense.</div><div><div>
<br><div><div>On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" <<a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<div 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; 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>
</div>
</blockquote></div><br></div></div></body></html>