[M3devel] size_t?

[hendrik at topoi.pooq.com]

On Tue, Feb 12, 2008 at 01:05:39AM +0000, 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?

The real requirement on size_t is that values of that type can be used 
freely in address arithmetic.

-- hendrik