Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: FAQ - malloc array - clarify
Keywords: malloc, Sun, lint
Message-ID: <26501@mimsy.umd.edu>
Date: 12 Sep 90 06:43:16 GMT
References: <8056@helios.TAMU.EDU> <1990Sep08.022034.8444@virtech.uucp> <1806@tuvie>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 35

In article <1806@tuvie> hp@vmars.tuwien.ac.at (Peter Holzer) writes:
[part of an aside:]
>The lint libraries are ASCII files on our system. Are they in a compiled 
>form on yours ?

Yes; they are built from ASCII files which are also installed.  The
situation differs under some versions of System V.

>In <sys/types.h>:
>	typedef int size_t;	/* returned by sizeof */
>				/* this is a compiler bug.
>				   should be unsigned	*/

The `size_t' you find in <sys/types.h> is *NOT* the `size_t' meant by
ANSI C.  <sys/types.h>'s `size_t' is the `size of a text, data, or
stack segment in clicks', not the `size of a contiguous memory block
in bytes'.  They merely (unfortunately) happen to have the same name.

In 4.3BSD-reno, the `size_t' in <sys/types.h> has been renamed `segsz_t'
and a proper (unsigned) size_t is defined in the proper ANSI <std*.h>
files.

One can fix this on binary-only Unix systems by changing that one line
in <sys/types.h> to read

	typedef int segsz_t;
	#ifdef KERNEL
	#define size_t segsz_t
	#endif

Unfortunately, you have to remember to reinstall this change with every
system upgrade until your vendor catches on.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris