[M3devel] size_t?

[Jay]

I think ANSI C is a bit of a mess here.
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...
 
Anyway..
But there are some symbols, such as size_t, that you can get from multiple headers, directly or indirectly.
For example, strlen returns size_t, so #include <string.h> must define it (directly or indirectly).
Malloc takes size_t, so #include <stdlib.h> must define it (directly or indirectly).
fread/fwrite/stdio.h ditto.
 
I don't know if string.h/stdlib.h/stdio.h are speced as exposing all of stddef.h however.
IF NOT, then there must be some underlying implementation defined layer, OR the headers have to duplicate the definition.
 
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.
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).
 
Pushing some things into fewer larger integers is a step in this direction.
It breaks "modularity" and so should be done very selectively, but /arguably/ size_t and ptrdiff_t are fundamental enough to warrant such treatment.
 
So I guess my point is that size_t and ptrdiff_t should perhaps be in the language.
Or, ok, ptrdiff_t == INTEGER, guaranteed, always and forever, on all targets, no question.
So maybe just size_t is missing?
 
I guess maybe it is BITS BITSIZE(INTEGER) FOR 0..LAST(INTEGER) ?
Good enough?
 
Really, I'm sure you have all figured out, I want Modula-3 to look more like C. :)
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..
 
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. :)
 
I also like that a decent module system was worked out such as to build fast, at least when using the integrated backend.
So maybe I just write all my Modula-3 as "unsafe" and be happy. :)
 
 - Jay



> CC: m3devel at elegosoft.com> From: hosking at cs.purdue.edu> Subject: Re: [M3devel] size_t?> Date: Mon, 11 Feb 2008 18:37:56 -0500> To: jayk123 at hotmail.com> > Yes, the ANSI C standard defines size_t and ptrdiff_t in stddef.h.> > Subtracting two pointers yields ptrdiff_t, so in M3 it would > presumably be INTEGER.> size_t is what sizeof returns, so I imagine size_t=CARDINAL is > probably OK (to match BITSIZE/BYTESIZE/ADRSIZE), but maybe should > better be Word.T to match C's unsigned interpretation. Of course, > Word.T is simply INTEGER anyway in the current CM3 implementation. > Note that neither of these need to be defined in the 32bit/64bit > subdirectories since they are straightforwardly the same as the > underlying word size.> > On Feb 11, 2008, at 5:34 PM, Jay wrote:> > > I did later notice size_t was there.> > I think what I earlier noticed was ptrdiff_t nowhere.> >> > > size_t = INTEGER.> >> > But unsigned presumably?> >> > What I had was correct, right?> > In C++ no header is needed for size_t, it is just so basic and > > widespread.> > Not sure about ptrdiff_t.> >> > Either way, they both do live in that middle ground between > > compiler and library -- a very low level --> > as size_t is defined as the type of sizeof() expressions and > > ptrdiff_t is defined as the type you get when you subtract > > pointers. And you don't need nay header to use sizeof() or subtract > > pointers.> >> > If it were really up to me, I'd have the Modula-3 language > > predefine all of int8, uint8, int16, uint16, int32, uint32, int64, > > uint64, size_t, ptrdiff_t, and maybe char and wchar_t and INTEGER.> > There is a corralary dilemna here that I haven't figured out, and > > have seen code address that I haven't adjusted to yet. That is, the > > code uses uint32 "everywhere", instead of something "more abstract/ > > vague". When it comes down to it, I suspect this is the right > > thing. The abstraction only seems to buy problems. UNLESS you have > > a processor with a larger natural integer that performs poorly on > > smaller integers, or a processor that perfs badly with 32 bit > > integers.> >> > Perhaps Modula-3 has solved it ok, in that INTEGER == ptrdiff_t.> > In many and growing systems, "int", besides its signedness, is too > > small for many occurences.> > That is the problem I think in C. If Modula-3 has essentially > > defined INTEGER to be the size of a pointer, then ok.> >> > - Jay> >> >> > > CC: m3devel at elegosoft.com> > > From: hosking at cs.purdue.edu> > > Subject: Re: [M3devel] size_t?> > > Date: Mon, 11 Feb 2008 17:04:10 -0500> > > To: jayk123 at hotmail.com> > >> > > Sorry.> > >> > > They belong in Cstddef.i3. size_t is already there. Let's try to> > > stick to the C ".h" structure.> > >> > > size_t = INTEGER.> > >> > > On Feb 11, 2008, at 4:51 PM, Jay wrote:> > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > >> > > > 1) There is no Utypes on Windows.> > > > These are very basic types that belong at a very low level.> > > > In C++ for example, size_t is provided "automatically" by the> > > > compiler, no header is needed.> > > >> > > > 2) Are they really OS dependent? What OS makes my definitions > > wrong?> > > > On what 32 bit architecture is size_t not an unsigned 32 bit> > > > integer and ptrdiff_t not a signed 32 bit integer?> > > > Ditto for 64 bit.> > > > These should always be the same size as a pointer and with the> > > > proper signedness.> > > > Even if some of the *.i3 files make size_t = int, is that really> > > > correct?> > > > And, I assume int vs. long issue is not an issue here.> > > > Though they may be different types in C and C++, they need not be> > > > in Modula-3 (when they are the same size, of course)> > > >> > > > - Jay> > > >> > > >> > > >> > > > > CC: m3devel at elegosoft.com> > > > > From: hosking at cs.purdue.edu> > > > > Subject: Re: [M3devel] size_t?> > > > > Date: Mon, 11 Feb 2008 11:38:48 -0500> > > > > To: jayk123 at hotmail.com> > > > >> > > > >> > > > > On Feb 11, 2008, at 6:23 AM, Jay wrote:> > > > >> > > > > > C:\dev2\cm3.2\m3-libs\m3core\src\C\Common\Cstddef.i3(12): > > size_t => > > > > > INTEGER;> > > > > >> > > > > > really? it is signed?> > > > > > and we are sure this is going to be 64 bits on 64 bit targets?> > > > > >> > > > > > size_t and ptrdiff_t ought to be in BasicCtypes, right?> > > > > > That has a 32 bit and 64 bit version, at least.> > > > >> > > > > These are OS-dependent! They should not be in BasicCtypes.> > > > >> > > > > >> > > > > >> > > > > > Does INTEGER effectively equal int or ptrdiff_t?> > > > > >> > > > > > - Jay> > > >> > > > Need to know the score, the latest news, or you need your > > Hotmail®-> > > > get your "fix". Check it out.> > >> >> >> > Climb to the top of the charts! Play the word scramble challenge > > with star power. Play now!> 
_________________________________________________________________
Helping your favorite cause is as easy as instant messaging. You IM, we give.
http://im.live.com/Messenger/IM/Home/?source=text_hotmail_join
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080212/423db7ad/attachment-0002.html>