retiring gets(3)

[Chris Torek]

In article <4509 at aldebaran.UUCP> jimp at cognos.uucp (Jim Patterson) writes:
>Realistically, though, are there REALLY C implementations out there
>which don't take binary 0 to be a NULL pointer, or a floating-point
>datum of all zero bits to be other than 0.0?

The S1 project at LLL built such a machine, and the people working
on it eventually gave in and made all-bits-zero be a nil pointer.
It was less work than fixing all the incorrect programs.

>Data General MV systems have instructions which take -1 as the null
>pointer value....  the C implementation still considers a
>null pointer to be 0 even though this requires quite a bit of "glue"
>around some system calls to interface between the two formats.
>Requiring that the "null pointer constant" be 0, as ANSI C does, just
>makes any other implementation painfully difficult (and is begging for
>problems when porting software as well).

It is neither particularly painful nor difficult, but it is indeed
begging to expose all the old bugs (similar to what Sun did when
porting 4.2BSD onto their hardware, where *(char *)0 was not 0, but
rather `segmentation fault').

>Where a good implementation of calloc() can shine is in virtual memory
>(VM) environments where it can avoid actually faulting in the pages
>that you allocate. ... demand-page-zero page type ... (VAX VMS is one
>system that supports this).

4BSD Unix also supports it.

While this is true, it is also true that malloc() can avoid faulting in
the pages too, if you simply leave them unset.  For bounded operations
(i.e., you are not going to go referencing the uninitialised memory)
this is just as efficient: pages not used are not touched.  Of course,
unset memory is a good place for bugs to hide.

(If you want to get really silly, memset() could ask the O/S to map out
any full pages, marking them as `c'-fill, where c is what memset is to
fill with.  I wonder if this would actually ever pay off?)
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris