[M3devel] size_t?

[Tony Hosking]

C and Modula-3 fill different needs.  I use C when it makes sense.  I  
use Modula-3 when it makes sense.  I'd hate to blur the distinction  
between them though!

On Feb 11, 2008, at 8:05 PM, Jay wrote:

> 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. Learn more.