<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>
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: m3devel@elegosoft.com<BR>From: hosking@cs.purdue.edu<BR>To: jayk123@hotmail.com<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_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px 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_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate"><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px 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_Apple-interchange-newline>
<BLOCKQUOTE><SPAN class=EC_Apple-style-span style="WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; LETTER-SPACING: normal; BORDER-COLLAPSE: separate">
<DIV class=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_Apple-converted-space> </SPAN><A href="mailto:jayk123@hotmail.com">jayk123@hotmail.com</A><BR>> To:<SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> Currently the various Utypes.i3 introduce various types LIKE<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> sometimes there is an underscore after the u.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> I am also willing to have u_* types and CAPITALIZED types:<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> There are roughly three or four perspectives here:<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> 3) This is my recently acquired perspective, but it isn't new.<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> Here is an exception I said I would detail:<BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=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_Apple-converted-space> </SPAN><BR>><SPAN class=EC_Apple-converted-space> </SPAN><BR>> - Jay<BR><BR></DIV></SPAN></BLOCKQUOTE></DIV><BR></BLOCKQUOTE></body>
</html>