Date: Tue, 10 Oct 1995 13:47:41 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: ache@astral.msk.su (=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=) Cc: terry@lambert.org, wollman@lcs.mit.edu, Kai.Vorma@hut.fi, current@freebsd.org Subject: Re: tail dumps core Message-ID: <199510102047.NAA11036@phaeton.artisoft.com> In-Reply-To: <Qkh_iUmuYc@ache.dialup.demos.ru> from "=?KOI8-R?Q?=E1=CE=C4=D2=C5=CA_=FE=C5=D2=CE=CF=D7?=" at Oct 10, 95 10:56:27 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> >> > Why not use 'calloc' instead? bzero isn't portable way. > >> > Theoretically 'calloc' can do some internal optimization of zeroing. > >> > >> Neither of these are portable unless the array being cleared is > >> composed of characters. There is almost never any reason to use > >> calloc(3). > > >I don't understand where you see a non-portability. Can you please > >explain? Thanks. > > > I mean not action (zeroing) but interface used only. > bzero isn't POSIX function. calloc is. Oh, I understand that; I was commenting on the "neither" including the calloc. Garret's point of a double 0 not being a 0 bit value is valid, even though it is really stretching things. I wouldn't expect a double value to be zero if the structure had been zero'ed, futher using a double as a flag value (the only real reason for a pre-zero) is not really good programming because of the overhead involved. You could still do it with a non-explicit cast, though. I don't see how the int/short/long/char atomic integer types aren't correct on all two's complement machines, though (ie: all recent commercially available machines). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510102047.NAA11036>