size_t (was: A lint question)

Ray Butterworth rbutterworth at watmath.waterloo.edu
Fri Dec 2 03:50:26 AEST 1988


In article <777 at quintus.UUCP>, ok at 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 ?-)




More information about the Comp.lang.c mailing list