Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!unmvax!ncar!tank!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: size_t (was: A lint question)
Message-ID: <14765@mimsy.UUCP>
Date: 30 Nov 88 18:53:40 GMT
References: <1256@vsedev.VSE.COM> <766@quintus.UUCP> <14750@mimsy.UUCP> <777@quintus.UUCP>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 24

In article <777@quintus.UUCP> ok@quintus.uucp (Richard A. O'Keefe) writes:
>... I assumed that it was the size_t of the dpANS.  I'm sorry to hear
>that this was just good luck.

I am not sure it can be called `good': having had a different definition,
replacing it with the Officially Proper version may break existing software.

>What *is* the size_t in [the 4BSD]  for, then?

Sizes, of course!

[gyre65] cd /sys/sys; egrep size_t kern_exec.c
kern_exec.c:    size_t ts, ds, ids, uds, ss;
kern_exec.c:                (long)(1 + ts/CLSIZE), (size_t)btoc(ep->a_data));
[gyre66]

Here it holds the size of text, data, and stack segments.  (ids and uds
are initialised and uninitialised---bss---regions respectively; ds is
approximately their sum.)  In most cases it would not matter if this
`size_t' were unsigned.  But the name should probably change, perhaps
to something like `segment size' (segsz_t?).
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris