Date: Tue, 10 Oct 1995 14:12:01 -0600 From: Nate Williams <nate@rocky.sri.MT.net> To: "Garrett A. Wollman" <wollman@lcs.mit.edu> Cc: Nate Williams <nate@rocky.sri.MT.net>, current@freebsd.org Subject: Re: tail dumps core Message-ID: <199510102012.OAA22172@rocky.sri.MT.net> In-Reply-To: <9510102001.AA10553@halloran-eldar.lcs.mit.edu> References: <9510101735.AA10192@halloran-eldar.lcs.mit.edu> <199510101836.LAA10827@phaeton.artisoft.com> <9510101901.AA10410@halloran-eldar.lcs.mit.edu> <199510101943.NAA22092@rocky.sri.MT.net> <9510102001.AA10553@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> > So, what's your point? Other than some comments in this set of lines > > > which implies that memset doesn't have to set an integer to all zeros, > > what's the problem? How does the C standard allow for memseting an int > > to be non-zero? > > The same way it allows for memsetting a pointer to be non-NULL: it > makes no guarantees whatsoever about the underlying bitwise > representation of its data types in memory. You're implying that a 'int i = 0' doesn't assume that the memory location doesn't contain the bytes '0x0000', correct? The prototype of memset() implies that it will indeed set all of the bytes of the underlying data type to the byte value specified in the second arguement. > My point in saying this is not to say that for all practical purposes > you can't depend on this, but rather to say that arguments suggesting > that `calloc' is somehow ``more portable'' are completely specious. I disagree. It is common to assume that sizeof(char) == 8 bits, but this isn't specified anywhere either but most code written would break if this were not true. Using 'calloc()' is much more portable than using bzero(), simply because bzero doesn't exist on many OS's while memset() does. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510102012.OAA22172>