From owner-freebsd-current  Sat Oct 14 16:39:48 1995
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id QAA22790
          for current-outgoing; Sat, 14 Oct 1995 16:39:48 -0700
Received: from pelican.com (pelican.com [134.24.4.62])
          by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id QAA22785
          for <current@freebsd.org>; Sat, 14 Oct 1995 16:39:43 -0700
Received: from puffin.pelican.com by pelican.com with smtp
	(Smail3.1.28.1 #5) id m0t4Edf-000K2yC; Sat, 14 Oct 95 15:01 WET DST
Received: by puffin.pelican.com (Smail3.1.29.1 #9)
	id m0t4Edf-0000ReC; Sat, 14 Oct 95 15:01 PDT
Message-Id: <m0t4Edf-0000ReC@puffin.pelican.com>
Date: Sat, 14 Oct 95 15:01 PDT
From: pete@puffin.pelican.com (Pete Carah)
To: current@freebsd.org
Subject: Re: tail dumps core
In-Reply-To: <199510102047.NAA11036@phaeton.artisoft.com>
Sender: owner-current@freebsd.org
Precedence: bulk

In article <199510102047.NAA11036@phaeton.artisoft.com> you write:

>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).


PR1ME used a non-zero for NULL pointers (at least to char), and also had
sizeof (char *) not equal to sizeof(int *).

AM29k systems (and any other purely word-addressed system without extra
bits in a word like a cray has) would likely have this last property too.

-- Pete