Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn )
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <8913@smoke.BRL.MIL>
Date: 18 Nov 88 02:35:38 GMT
References: <1988Nov8.054845.23998@utstat.uucp> <7963@bloom-beacon.MIT.EDU> <4509@aldebaran.UUCP>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 25

In article <4509@aldebaran.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>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).

Please get your facts straight before complaining.  C has always
allowed a null pointer constant to be written as 0.  ANSI C merely
makes (void*)0 a valid alternative way to write a null pointer
constant.  (K&R C didn't have void*.)

The contexts where a null pointer constant are being used aren't
all that hard for a compiler to determine, and it can generate
whatever code is necessary for such cases.  By no means is an
all-0-bit representation forced on the implementation.

>It's worth noting that pre-clearing memory shouldn't be considered
>wasted overhead on the part of the OS. It's an important security
>precaution, to prevent other system users from poking through memory
>that used to belong to someone else and which could contain sensitive
>information. This may not be important to all users, but it is to
>many.

All the UNIX implementations I know of arrange for extended program
break memory (heap) and stack to be zeroed.  It would be even safer
to zero it just before relinquishing process ownership of it.