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