Path: utzoo!utgpu!watmath!clyde!att!pacbell!ames!sgi!arisia!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.lang.c Subject: Re: size_t (was: A lint question) Message-ID: <777@quintus.UUCP> Date: 30 Nov 88 10:26:06 GMT References: <1256@vsedev.VSE.COM> <766@quintus.UUCP> <14750@mimsy.UUCP> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 18 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. 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 but "int" in 4.2's , 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 for, then?