[M3devel] size_t?

[Tony Hosking]

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!