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