<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>I think ANSI C is a bit of a mess here.<BR>
For the most part, no header is defined as #including any other. That is good. Each header exposes certain names and few names are exposed by more than one header. As well, for good measure, your own #includes of ANSI C headers I believe is speced as order-independent. These are all aspects of a "good module system", except this solid foundation is built on a foundation of quicksand and there is inadequate support for it in the language -- i.e. no static enforcement...<BR>
<BR>
Anyway..<BR>
But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly.<BR>
For example, strlen returns size_t, so #include <string.h> must define it (directly or indirectly).<BR>
Malloc takes size_t, so #include <stdlib.h> must define it (directly or indirectly).<BR>
fread/fwrite/stdio.h ditto.<BR>
<BR>
I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however.<BR>
IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition.<BR>
<BR>
This notion of combining one interface into another wholesale is probably usually a bad idea, but it can also be darn convenient. Just #include everything, and have everything available in the global namespace.<BR>
The "language" does live in this space. INTEGER is ALWAYS available and always has the same meaning (per-target). I cannot redefine it (again, other than by making a new target).<BR>
<BR>
Pushing some things into fewer larger integers is a step in this direction.<BR>
It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment.<BR>
<BR>
So I guess my point is that size_t and ptrdiff_t should perhaps be in the language.<BR>
Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question.<BR>
So maybe just size_t is missing?<BR>
<BR>
I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ?<BR>
Good enough?<BR>
<BR>
Really, I'm sure you have all figured out, I want Modula-3 to look more like C. :)<BR>
The more I use C lately (as opposed to C++) and the more I use Modula-3 lately..the more I find C perfectly ok, the unsafety easy enough to not be bitten by, the more the heap allocations and copying that "safety" cost seem not worth it..<BR>
<BR>
It's an interesting system largely just because it is yet another system, in need (arguably) of more targets, and where "NT386" exists but gets little support. Someone who "likes" Modula-3 more would serve it better than me, perhaps. But I'm here. :)<BR>
<BR>
I also like that a decent module system was worked out such as to build fast, at least when using the integrated backend.<BR>
So maybe I just write all my Modula-3 as "unsafe" and be happy. :)<BR>
<BR>
- Jay<BR><BR>
<HR id=stopSpelling>
<BR>
> CC: m3devel@elegosoft.com<BR>> From: hosking@cs.purdue.edu<BR>> Subject: Re: [M3devel] size_t?<BR>> Date: Mon, 11 Feb 2008 18:37:56 -0500<BR>> To: jayk123@hotmail.com<BR>> <BR>> Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h.<BR>> <BR>> Subtracting two pointers yields ptrdiff_t, so in M3 it would <BR>> presumably be INTEGER.<BR>> size_t is what sizeof returns, so I imagine size_t=CARDINAL is <BR>> probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should <BR>> better be Word.T to match C's unsigned interpretation. Of course, <BR>> Word.T is simply INTEGER anyway in the current CM3 implementation. <BR>> Note that neither of these need to be defined in the 32bit/64bit <BR>> subdirectories since they are straightforwardly the same as the <BR>> underlying word size.<BR>> <BR>> On Feb 11, 2008, at 5:34 PM, Jay wrote:<BR>> <BR>> > I did later notice size_t was there.<BR>> > I think what I earlier noticed was ptrdiff_t nowhere.<BR>> ><BR>> > > size_t = INTEGER.<BR>> ><BR>> > But unsigned presumably?<BR>> ><BR>> > What I had was correct, right?<BR>> > In C++ no header is needed for size_t, it is just so basic and <BR>> > widespread.<BR>> > Not sure about ptrdiff_t.<BR>> ><BR>> > Either way, they both do live in that middle ground between <BR>> > compiler and library -- a very low level --<BR>> > as size_t is defined as the type of sizeof() expressions and <BR>> > ptrdiff_t is defined as the type you get when you subtract <BR>> > pointers. And you don't need nay header to use sizeof() or subtract <BR>> > pointers.<BR>> ><BR>> > If it were really up to me, I'd have the Modula-3 language <BR>> > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, <BR>> > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.<BR>> > There is a corralary dilemna here that I haven't figured out, and <BR>> > have seen code address that I haven't adjusted to yet. That is, the <BR>> > code uses uint32 "everywhere", instead of something "more abstract/ <BR>> > vague". When it comes down to it, I suspect this is the right <BR>> > thing. The abstraction only seems to buy problems. UNLESS you have <BR>> > a processor with a larger natural integer that performs poorly on <BR>> > smaller integers, or a processor that perfs badly with 32 bit <BR>> > integers.<BR>> ><BR>> > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.<BR>> > In many and growing systems, "int", besides its signedness, is too <BR>> > small for many occurences.<BR>> > That is the problem I think in C. If Modula-3 has essentially <BR>> > defined INTEGER to be the size of a pointer, then ok.<BR>> ><BR>> > - Jay<BR>> ><BR>> ><BR>> > > CC: m3devel@elegosoft.com<BR>> > > From: hosking@cs.purdue.edu<BR>> > > Subject: Re: [M3devel] size_t?<BR>> > > Date: Mon, 11 Feb 2008 17:04:10 -0500<BR>> > > To: jayk123@hotmail.com<BR>> > ><BR>> > > Sorry.<BR>> > ><BR>> > > They belong in Cstddef.i3. size_t is already there. Let's try to<BR>> > > stick to the C ".h" structure.<BR>> > ><BR>> > > size_t = INTEGER.<BR>> > ><BR>> > > On Feb 11, 2008, at 4:51 PM, Jay wrote:<BR>> > ><BR>> > > > > These are OS-dependent! They should not be in BasicCtypes.<BR>> > > ><BR>> > > > 1) There is no Utypes on Windows.<BR>> > > > These are very basic types that belong at a very low level.<BR>> > > > In C++ for example, size_t is provided "automatically" by the<BR>> > > > compiler, no header is needed.<BR>> > > ><BR>> > > > 2) Are they really OS dependent? What OS makes my definitions <BR>> > wrong?<BR>> > > > On what 32 bit architecture is size_t not an unsigned 32 bit<BR>> > > > integer and ptrdiff_t not a signed 32 bit integer?<BR>> > > > Ditto for 64 bit.<BR>> > > > These should always be the same size as a pointer and with the<BR>> > > > proper signedness.<BR>> > > > Even if some of the *.i3 files make size_t = int, is that really<BR>> > > > correct?<BR>> > > > And, I assume int vs. long issue is not an issue here.<BR>> > > > Though they may be different types in C and C++, they need not be<BR>> > > > in Modula-3 (when they are the same size, of course)<BR>> > > ><BR>> > > > - Jay<BR>> > > ><BR>> > > ><BR>> > > ><BR>> > > > > CC: m3devel@elegosoft.com<BR>> > > > > From: hosking@cs.purdue.edu<BR>> > > > > Subject: Re: [M3devel] size_t?<BR>> > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500<BR>> > > > > To: jayk123@hotmail.com<BR>> > > > ><BR>> > > > ><BR>> > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote:<BR>> > > > ><BR>> > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): <BR>> > size_t =<BR>> > > > > > INTEGER;<BR>> > > > > ><BR>> > > > > > really? it is signed?<BR>> > > > > > and we are sure this is going to be 64 bits on 64 bit targets?<BR>> > > > > ><BR>> > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?<BR>> > > > > > That has a 32 bit and 64 bit version, at least.<BR>> > > > ><BR>> > > > > These are OS-dependent! They should not be in BasicCtypes.<BR>> > > > ><BR>> > > > > ><BR>> > > > > ><BR>> > > > > > Does INTEGER effectively equal int or ptrdiff_t?<BR>> > > > > ><BR>> > > > > > - Jay<BR>> > > ><BR>> > > > Need to know the score, the latest news, or you need your <BR>> > Hotmail®-<BR>> > > > get your "fix". Check it out.<BR>> > ><BR>> ><BR>> ><BR>> > Climb to the top of the charts! Play the word scramble challenge <BR>> > with star power. Play now!<BR>> <BR><BR><br /><hr />Helping your favorite cause is as easy as instant messaging. You IM, we give. <a href='http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join' target='_new'>Learn more.</a></body>
</html>