Path: utzoo!mnetor!uunet!steinmetz!davidsen
From: davidsen@steinmetz.steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.lang.c
Subject: Re: Why NULL is 0
Message-ID: <10282@steinmetz.steinmetz.ge.com>
Date: 6 Apr 88 14:00:23 GMT
References: <10229@steinmetz.steinmetz.ge.com> <432@goofy.megatest.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 30

In article <432@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:

| SPARC?  Really?  REALLY??   What have they done?  Please clarify.

  My understanding of SPARC, having read documentation and tried some
programs, is that SPARC requires that int, float, and long be alligned
rather than on an arbitrary boundary. This means that just typing a
pointer to char or short as pointer to {int long float double} will not
produce code which loads consecutive bytes starting at the 1st character
address.

  If you might be doing something like building a raw data buffer, by:
	*((int *)bufptr = intval;	/* char *bufptr */
	bufptr += sizeof(int);
it is portable to any machine which doesn't require allignment, but for
true portability something like the following must be done:
	memncpy(bufptr, &intval, sizeof int);
	bufptr += sizeof int;

  I am not claiming or even implying that this is going to break any
large number of programs, just that SPARC has more restrictions on
addressing than the 68000 series.  I don't have dpANS here, there may be
a better procedure to use than memncpy. 

  It also means that structures are not packed the same way in some
cases, I assume, but was not able to verify.
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs | seismo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me