<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Cstdint.i3 seems perfectly reasonable as per: <a href="http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html">http://www.opengroup.org/onlinepubs/009695399/basedefs/stdint.h.html</a></div><div><div><div apple-content-edited="true"><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><div style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><span class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><br class="Apple-interchange-newline"></span></div></span> </div><div><div>On Jun 2, 2008, at 11:34 AM, Jay wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div class="hmmessage" style="font-size: 10pt; font-family: Tahoma; ">> I want to add these somewhere in m3core.<br><br>Ok, how about this? I think we can agree to this easily.<br> <br>INTERFACE Cstdint;<br> <br>IMPORT Ctypes;<br><br>TYPE<br><br>int8_t = Ctypes.signed_char;<br>uint8_t = Ctypes.unsigned_char;<br><br>int16_t = Ctypes.short;<br>uint16_t = Ctypes.unsigned_short;<br><br>int32_t = Ctypes.int;<br>uint32_t = Ctypes.unsigned_int;<br><br>int64_t = Ctypes.long_long;<br>uint64_t = Ctypes.unsigned_long_long;<br><br>(* from here on out I don't care much, can be removed to avoid being wrong *)<br><br>intptr_t = INTEGER;<br>uintptr_t = CARDINAL; (* ? *)<br><br>(* and esp. from here on out if there is any difficulty coming up with the definitions *)<br><br>CONST<br><br>PTRDIFF_MIN = FIRST(intptr_t);<br>SIZE_MAX = LAST(uintptr_t);<br><br>(* Should WCHAR be wchar_t, or be 16 bits always?<br>wchar_t is sometimes larger than 16 bits. *)<br><br>WCHAR_MIN = FIRST(WIDECHAR);<br>WCHAR_MAX = LAST(WIDECHAR);<br><br>(* The rest omitted as decreasing usefulness and possibly decreasing portability. *)<br><br>I would just as soon integrate all this into the language as globals<br>but people like to push stuff out to libraries where possible/easy.<br>(Some C++ libraries -- Boost -- have become very contorted because it was possible but not easy.)<br><br> - Jay<br><br><br><br><br><br><blockquote><hr>From:<span class="Apple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>Subject: RE: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3<br>Date: Mon, 2 Jun 2008 10:13:41 +0000<br><br>They are not from the C standard, nor are they necessarily from a particular platform.<br>Some platforms define some of them.<br>But all platforms could define all of them, at least 8/16/32, and could define them identically.<br>I want to add these somewhere in m3core.<br>They are portable enough.<br> <br> - Jay<br><blockquote><hr>CC:<span class="Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>From:<span class="Apple-converted-space"> </span><a href="mailto:hosking@cs.purdue.edu">hosking@cs.purdue.edu</a><br>To:<span class="Apple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><br>Subject: Re: [M3devel] FW: proposal/insistence for fixed size integer types in Ctypes.i3<br>Date: Mon, 2 Jun 2008 10:23:44 +0100<br><br><div><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><div style="word-wrap: break-word; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><div>Are these types defined by the C standard. If not then they don't belong in Ctypes. If they are only defined by their particular platform then they do belong in Utypes.</div></span></span></span></span></span></span></span></span></div></span></div><br><div><div>On Jun 1, 2008, at 3:35 AM, Jay wrote:</div><br class="EC_EC_Apple-interchange-newline"><blockquote><span class="EC_EC_Apple-style-span" style="word-spacing: 0px; font: normal normal normal 12px/normal Helvetica; text-transform: none; color: rgb(0, 0, 0); text-indent: 0px; white-space: normal; letter-spacing: normal; border-collapse: separate; "><div class="EC_EC_hmmessage" style="font-size: 10pt; font-family: Tahoma; ">So much for trying plain text to avoid truncation, darnit.<br><br><br><br>> From:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</a><br>> To:<span class="EC_EC_Apple-converted-space"> </span><a href="mailto:m3devel@elegosoft.com">m3devel@elegosoft.com</a><br>> Subject: proposal/insistence for fixed size integer types in Ctypes.i3<br>> Date: Sun, 1 Jun 2008 02:32:27 +0000<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Currently the various Utypes.i3 introduce various types LIKE<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> uint8_t = unsigned_char;<br>> uint16_t = unsigned_short;<br>> uint32_t = unsigned_int;<br>> uint64_t = unsigned_long_long;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> int8_t = signed_char;<br>> int16_t = short;<br>> int32_t = int;<br>> int64_t = long_long;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> sometimes there is an underscore after the u.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> There is quite some variation in which, if any, of these types are provided.<br>> When they are provided, they are always the same, with one exception I will detail.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Arguably they are provided only for defining other types and function signatures<br>> within m3-libs/m3core/src/unix.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> I strongly strongly strongly propose that at least the above 8 types go in<br>> Ctypes, and the definitions in Utypes removed.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> If there was more commonality in Utypes, I'd "forward" them for compatibility,<br>> but there is little commonality. Code depending on these types would have to<br>> be forked a lot. As I said, the types are always the same, if they are defined,<br>> but they are often not defined.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> One variation I am open to is introducing a new .i3 file.<br>> But in general I like to colocate stuff rather than pick apart everything<br>> and decide an ideal location. There are tradeoffs either way,<br>> though most people only see the tradeoffs in the way I do it.<br>> The tradeoffs the other way are having to track down module after module,<br>> interface after interface, where to get stuff from, rather than having<br>> a "one stop shop", or "fewer shops to stop".<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> I am also willing to have u_* types and CAPITALIZED types:<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> uint8_t = unsigned_char;<br>> uint16_t = unsigned_short;<br>> uint32_t = unsigned_int;<br>> uint64_t = unsigned_long_long;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> int8_t = signed_char;<br>> int16_t = short;<br>> int32_t = int;<br>> int64_t = long_long;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> u_int8_t = uint8_t;<br>> u_int16_t = uint16_t;<br>> u_int32_t = uint32_t;<br>> u_int64_t = uint64_t;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> UINT8 = uint8_t;<br>> UINT16 = uint16_t;<br>> UINT32 = uint32_t;<br>> UINT64 = uint64_t;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> INT8 = int8_t;<br>> INT16 = int16_t;<br>> INT32 = int32_t;<br>> INT64 = int64_t;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> All built-in Modula-3 types are capitalized, as all Modula-3 keywords are.<br>> And capitalized types is a style widely used in the Windows headers.<br>> (Windows and Modula-3 share a common heritage -- Digital -- though I don't know<br>> from where the style of capitalized types originates.)<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> The names "int8", "int16" are also obvious candidates, but I feel that some<br>> amount of typographical convention should be used to demark types.<br>> Some amount of "Hungarian", if you will.<br>> Obviously there are vehement opposing opinions on this.<br>> "Hungarian" is often too precise and precludes changing types without<br>> changing names, as well as producing unpronouncable names.<br>> A "weak" form however seems reasonable and useful.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> These types represent a certain point of view.<br>> It is a common point of view, but not universal.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> There are roughly three or four perspectives here:<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> 1)<br>> char, short, int, long are abstractly defined and all code should live with it.<br>> char is at least 8 bits, and of unspecified signedness<br>> (limits.h defines CHAR_BIT, the number of bits in char<br>> for specified signedness, use signed char or unsigned char;<br>> I think char has actually three options for its signess -- signed, unsigned, or "half unsigned")<br>> short is at least 16 bits, signed<br>> int is at least 16 bits, signed<br>> long is at least 32 bits, signed<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> There are not necessarily integral types that can hold pointers.<br>> size_t and ptrdiff_t perhaps, but unclear.<br>> size_t can hold the size of anything, but I think "anything" is "any variable"<br>> and not necessarily "the entire address space".<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> ptrdiff_t can hold the result of subtracting pointers, but it is only<br>> valid to subtract pointers that point into the same array or just past it.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> It is common, for example, but not universal, for the "address space"<br>> to be divided between "user mode" and "kernel mode", often with a 50/50 split,<br>> so therefore size_t could be one bit smaller than a pointer, at least.<br>> Of course that's an "unnatural" size, but theoretically possible.<br>> (This kernel/user 50/50 split is usually exactly how 32 bit and I assume<br>> 64 bit Windows works, though 32 bit Windows can also have a 3 gig / 1 gig split,<br>> and 32 bit Windows code running on 64 bit Windows kernel can get a<br>> full 4 gig address space.)<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> As well, the representation of signed integers is left unspecified.<br>> The range of "int" need only go down to -32767, not necessarily -32768.<br>> Signed magnitude and one's complement are valid representations.<br>> Overflowing a signed integer causes undefined behavior.<br>> Unsigned numbers do not have this abstraction.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> While this is the "most correct" view, according to (my understanding) the C standard,<br>> implementations do nail down details way beyond this, and a lot of<br>> code depends on these details.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> While I may have some of those details slightly wrong, you get the point.<br>> You CAN write code within this interface, but a lot of code violates it, sometimes<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> by accident, sometimes for important practical reasons.<br>> Some amount of code assumes an int is at least or exactly 32 bits.<br>> Some amount of code assumes int or long can hold a pointer, though<br>> int probably not so much, and long probably of proportionally<br>> rapidly decreasing instance due to Win64.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> 2)<br>> char, short, int, long are somewhat abstractly defined<br>> char is exactly 8 bits<br>> varying perspectives on its presumed signedness<br>> short is exactly 16 bits<br>> int is exactly 32 bits<br>> long there are few perspectives on; it is exactly 32 bits ("Windows"), or<br>> it is exactly the size of a pointer ("Unix"), or it is at least<br>> the size of a pointer<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> As well, two's complement is the only representation of signed numbers<br>> in use, and code depends on this.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> (I recently read that we can thank the IBM S/360 or such, in the 1960's,<br>> for introducing such modern-day architectural features that everyone<br>> takes for granted as an 8 bit byte and two's complement signed numbers.)<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> If you need an integer with a particular exact size, either use char/short/int directly,<br>> or run them through "autoconf", or sniff "limits.h".<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> 3) This is my recently acquired perspective, but it isn't new.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Given that #1 is "correct but rare", and that #2 are<br>> full of "exact":<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> char, short, int, long are funny names with not particularly<br>> useful specifications. #2 is a little sleazy (less so if autoconfed/limits.h)<br>> Unless you are really adhering to the strict spec, don't use them.<br>> If you are in fact indexing a "small" array, they might suffice,<br>> but is it worth it? worth having these types?<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Theory: 16 bit machines are irrelevant and 32 bit integers<br>> are perfectly efficient on 64 bit machines, and 64 bit integers<br>> are universally available (?) and reasonably efficient (?),<br>> so feel free to use them if there is a need.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> As well, 4gig remains a large capacity in most contexts, so feel<br>> free to use explictly 32 bit integers.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> However file sizes and offsets should really always be 64 bits.<br>> Any code still requiring 32 bit file offsets/sizes is unfortunate.<br>> That includes PE32+ imho, the file format for .exes/.dlls on Win64.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Be clear and unsleazy and adopt new names that represent well<br>> their specification and actual use.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> int_t is exactly n bits in size and signed<br>> uint_t is exactly n bits in size and unsigned<br>> some names are chosen for unsigned and signed integers with<br>> the exact size of a pointer<br>> For n=8,16,32 all four types exist, and probably 64.<br>> And pointer-sized types exist.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> If you really feel your capacity limits should scale with address space size, or need<br>> to store a pointer in an integer, use size_t or uintptr_t or intptr_t, etc.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Modula-3's position here adds that INTEGER is the exact<br>> size of a pointer and signed. It is identical to ptrdiff_t<br>> or intptr_t. CARDINAL is the exact size but omits the bottom "half"<br>> of the range, and does not, I believe, extend the top "half".<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Now, I also realize, that m3-libs/m3core/src/unix is a fairly mechanical<br>> translation of /usr/include, and /usr/include does not necessarily<br>> take perspective #3. So the "funny" names are useful for a human<br>> mechanical translation. But the precise names can still be used instead.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Here is an exception I said I would detail:<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> irix-5.2/utypes.i3:<br>> int64_t = RECORD val := ARRAY[0..1] OF int32_t {0,0}; END;<br>> uint64_t = int64_t;<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> This is different in at least two ways that I see.<br>> - default initialization to zero<br>> - 32 bit alignment instead of 64 bit alignment<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> I tend to assume that the alignment is actually wrong,<br>> however all the uses in Usignal appear unaffected, as they are always preceded<br>> by a mix of int64_t and an even number of int32.<br>> Either way, it is easy enough to preserve this for compatibility.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> I would like to continue, where easy and clear, to reduce the "size" of m3-libs/m3core/src/unix.<br>> Making these types portable available helps that.<br>> For example -- Uin.m3 need not be duplicated at all.<br>> But then it either must use the presently more portable unsigned_short and unsigned,<br>> or uint16_t and uint32_t should be made always available, either by adding them<br>> to all the various Utypes.i3, or the one Ctypes.i3, or a new place.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> Darwin currently has four Upthread.i3 files (one is dead), but needs either only two, or one<br>> with the sizes abstracted out. I don't know if PPC64_DARWIN will needs its own yet,<br>> I don't have one of these machines yet.<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> I would like to go ahead with this stuff *today*.<br>> It takes some exertion of patience for me to stop and send this first. :)<br>><span class="EC_EC_Apple-converted-space"> </span><br>><span class="EC_EC_Apple-converted-space"> </span><br>> - Jay<br><br></div></span></blockquote></div><br></blockquote></blockquote></div></span><br class="Apple-interchange-newline"></blockquote></div><br></div></div></body></html>