<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'><div>1) Ctypes.int</div><div><br></div><div><br></div><div>2) I wrapped everything anyway because the rewriting of /usr/include in m3core/unix was terribly tedious and error prone and a frequent source of problems.</div><div>I favor size_t/INTEGER. The "direct" calls were not worth the trouble. I've debugged enough stack corruptions due to getting struct stat wrong there.</div><div><br></div><div><br></div><div>3) But not always, the Win32 and X windows stuff is still direct.</div><div><br></div><div>INTEGER is not the only integer type, it is just kinda the default easiest to use if you must use one, use it.</div><div>If you want to think more about it, there are more options.</div><div><br></div><div>The 8 underlying types are all in there -- 8/16/32/64 unsigned and signed.</div><div>Perhaps they should be exposes differently, like as INT8, UINT8, INT16, UINT16, INT32, UINT32, INT64, UINT64?</div><div>Or int8_t, uint8_t, int16_t, uint16_t, etc.?</div><div><br></div><div>Those types are all available to all programs, albeit in the WinNT and cstdint modules I believe. Not "global" like INTEGER.</div><div><br></div><div> - Jay<br><br><br><br></div><div><hr id="stopSpelling">Date: Thu, 28 May 2015 21:53:33 +0200<br>From: estellnb@elstel.org<br>To: hosking@purdue.edu<br>CC: m3devel@elegosoft.com; jay.krell@cornell.edu; rodney.m.bates@acm.org<br>Subject: Re: [M3devel] 64bit INTEGERs, WIDECHAR: language specified or configuration/target dependent?<br><br>
<div class="ecxmoz-cite-prefix"><br>
How for the hell do you interface with operating system services
requiring a 32bit int when you only have the 64bit INTEGER??<br>
<br>
Am 28.05.15 um 19:46 schrieb Elmar Stellnberger:<br>
</div>
<blockquote cite="mid:55675464.5090306@elstel.org">
<div class="ecxmoz-cite-prefix">Am 28.05.15 um 04:03 schrieb Antony
Hosking:<br>
</div>
<blockquote cite="mid:77605189-D966-4D4B-8946-838BD6E178AA@purdue.edu">
<pre>BYTESIZE(ADDRESS) = BYTESIZE(INTEGER) in cm3 on all target platforms. I don't really understand what you are proposing.
</pre>
</blockquote>
on AMD64: BITSIZE(INTEGER) = BITSIZE(LONGINT) = 64bit<br>
<br>
I have just noticed that and when taking a practical standpoint -
i.e. what really matters to new and old programs -<br>
this is a really bad decision which I wish to change for the next
release.<br>
<br>
If you have not examined it yet please reclaim the design
decisions for leaving int 32bit in C:<br>
<pre><i><big>However things turned out to be very different when the extension from
32bit to 64bit was at stake. There was no more gain by automatically
extending the value ranges from 2<sup class="ecxmoz-txt-sup"><span style="width: 0px; height: 0px; overflow: hidden; display: inline-block;">^</span>32</sup> to 2<sup class="ecxmoz-txt-sup"><span style="width: 0px; height: 0px; overflow: hidden; display: inline-block;">^</span>64</sup> for 95% of all application
purposes while the memory hierarchy has increasingly become a bottle
neck in recent time. Additionally doubling the size of all integers would
initially have doubled our memory needs which would have been a
potential drawback for introducing the AMD64 arch. Just think of a machine
with 4GB of RAM: It can not be addressed by 32bit (only ~3GB can) while
making all INTS 64bit would have shrunken our memory to an effective size
of 2GB. Luckily the decision was taken differently this time:
* keep all ints of at most 32bit and just extend pointers to 64bit
</big></i> </pre>
Same reasoning applies to Modula-3. - and I believe you have
failed to notice when <br>
making your decisions for cm3 5.8.6. Or do you want to tell me
that Modula-3 <br>
developers are more prudent than the C/C++ community?<br>
<br>
Even worse I have discovered the following:<br>
BITS 8 FOR INTEGER and BITS 32 FOR INTEGER do not work with cm3
5.8.6:<br>
<br>
:: BITS FOR size too small, must be at least (64)<br>
<br>
That will break existing legacy code when trying to compile it
with cm3 5.8.6. <br>
</blockquote>
<br></div> </div></body>
</html>