chris@mimsy.UUCP (Chris Torek) (11/30/88)
In article <766@quintus.UUCP> ok@quintus.uucp (Richard A. O'Keefe) writes: >size_t is an unsigned integral type (except in BSD systems, where it's "int"). The only `size_t' appearing in any 4BSD release is in <sys/types.h>. I have copied this from the 4.0BSD release (where the file was not even called types.h---this is from /usr/src/sys/h/param.h), dated no later than 1980, i.e., before ANSI C committees were even even a gleam in someone's eyes: typedef struct { int r[1]; } * physadr; typedef int daddr_t; typedef char * caddr_t; typedef unsigned short ino_t; typedef int swblk_t; typedef int size_t; typedef int time_t; typedef int label_t[14]; typedef short dev_t; typedef int off_t; Whether size_t should have been `unsigned int' even then is another question entirely. The point, however, is that the size_t found in 4BSD is not related to the size_t found in the dpANS, and hence not conformant. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
ok@quintus.uucp (Richard A. O'Keefe) (11/30/88)
In article <14750@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >In article <766@quintus.UUCP> ok@quintus.uucp (Richard A. O'Keefe) writes: >>size_t is an unsigned integral type (except in BSD systems, where it's "int"). >The only `size_t' appearing in any 4BSD release is in <sys/types.h>. That's the one I meant. >The point, however, is that the size_t found in >4BSD is not related to the size_t found in the dpANS, and hence not >conformant. "man types" in SunOS 3.2 lists the types and explains some of them, but not size_t. Since one of the differences between BSD and SysV is that read() and write() take "unsigned" length parameters in SysV but "int" ones in BSD, while size_t is "unsigned int" in V.3's <sys/types.h> but "int" in 4.2's <sys/types.h>, I assumed that it was the size_t of the dpANS. I'm sorry to hear that this was just good luck. What *is* the size_t in <sys/types.h> for, then?
chris@mimsy.UUCP (Chris Torek) (12/01/88)
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] <sys/types.h> 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
rbutterworth@watmath.waterloo.edu (Ray Butterworth) (12/02/88)
In article <777@quintus.UUCP>, ok@quintus.uucp (Richard A. O'Keefe) writes: > Since one of the differences between BSD and SysV is that > read() and write() take "unsigned" length parameters in SysV but "int" > ones in BSD, while size_t is "unsigned int" in V.3's <sys/types.h> but > "int" in 4.2's <sys/types.h>, I assumed that it was the size_t of the > dpANS. I'm sorry to hear that this was just good luck. What *is* > the size_t in <sys/types.h> for, then? The tahoe BSD defines size_t as (long) instead of (int) as in 4.2. This is a big improvement? P.S. I see that the "NULL == (char*)0" fallacy is starting up again. As long as we are getting rid of gets(), perhaps it is time to get rid of NULL too ?-)