<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p
{mso-style-priority:99;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas","serif";}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--Randy Coleburn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-left:.5in"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Tony Hosking [mailto:hosking@cs.purdue.edu]
<br>
<b>Sent:</b> Monday, September 30, 2013 11:46 AM<br>
<b>To:</b> Coleburn, Randy<br>
<b>Cc:</b> Jay K; m3devel<br>
<b>Subject:</b> EXT:Re: [M3devel] question on File.Status.size<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in">(I can imagine a world where there is no LONGINT, and in which Long.T has some different representation than LONGINT.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">So, should M3 adopt the POSIX spec that a file size is a signed value? In which case I suppose LONGCARD makes sense.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">On Sep 30, 2013, at 9:49 AM, "Coleburn, Randy" <<a href="mailto:rcolebur@SCIRES.COM">rcolebur@SCIRES.COM</a>> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-left:.5in"><br>
<br>
<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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). <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">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. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-left:.5in">Randy Coleburn<br>
<br>
Sent from my iPhone<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<br>
On Sep 30, 2013, at 12:48 AM, "Jay K" <<a href="mailto:jay.krell@cornell.edu">jay.krell@cornell.edu</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
> 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>
<o:p></o:p></p>
<div>
<div class="MsoNormal" align="center" style="margin-left:.5in;text-align:center">
<hr size="3" width="100%" align="center" id="stopSpelling">
</div>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
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<o:p></o:p></p>
<div>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">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:<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-left:.5in"><a name="idx.43"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">An</span></a><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> open array type declaration has the form:
<o:p></o:p></span></p>
<pre style="margin-left:.5in"> TYPE T = ARRAY OF Element<o:p></o:p></pre>
<p class="MsoNormal" style="margin-left:.5in"><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">where
</span><tt><span style="font-size:10.0pt">Element</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> is any type. The values of
</span><tt><span style="font-size:10.0pt">T</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> are arrays whose element type is
</span><tt><span style="font-size:10.0pt">Element</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> and whose length is arbitrary. The index type of an open array is the
</span><tt><b><span style="font-size:10.0pt">INTEGER</span></b></tt><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> subrange
</span></b><tt><span style="font-size:10.0pt">[0..n-1]</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">, where
</span><tt><span style="font-size:10.0pt">n</span></tt><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> is the length of the array.
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:12.0pt;margin-left:.5in">
<span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">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<o:p></o:p></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>