Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!ltuxa!ttrdc!levy
From: levy@ttrdc.UUCP (Daniel R. Levy)
Newsgroups: net.lang.c
Subject: Re: Yet another ALIGN idea.  (some discussion)
Message-ID: <1038@ttrdc.UUCP>
Date: Sun, 6-Jul-86 15:54:42 EDT
Article-I.D.: ttrdc.1038
Posted: Sun Jul  6 15:54:42 1986
Date-Received: Mon, 7-Jul-86 01:22:17 EDT
References: <1986Jun29.15:39:38.4762@utcs.uucp>
Organization: AT&T, Computer Systems Division, Skokie, IL
Lines: 44

In article 38.4762@utcs.uucp>, flaps@utcs.UUCP writes:
>How about an #include <align.h> which contains a single #define which gives the
>alignment constant for this machine?
>This of course would only be useful if put into the standard.
>Which reminds me, is sizeof(char) always = 1 yet?  I mean, is it guaranteed?
>ajr

Say if ajr's suggestion were implemented and /usr/include/align.h contained
something like

#define ALIGNSIZE 4	/* long int */

Now, given an arbitrary char* pointer, how do we tell if it is aligned?
Now on a machine with four-byte pointers and unsigned longs, we could do:

	char *c;
	...
	if (((unsigned long)c % ALIGNSIZE) == 0) {
		/* c is aligned */
		...
	} else {
		/* c is not aligned */
		...
	}

But... what about a machine where alignments are "screwy," for example they
wanted doubles to be located at some fixed offset, say 2, from addresses which
are integral multiples of 4 or 8?  I can think of no such machine (indeed I
believe design of such would be an exercise in masochism) but where is it
engraved in stone what "aligned" really means (which we presume must imply
some guarantee of solid mapping between pointers and some other data type,
usually long... I used unsigned long in my example because it would work
on a machine with one's complement arithmetic and pointers with their
MSB set, whereas a bit-pattern copy to a long would produce a number which
could not be reliably tested for alignment--but again we hope that the
mapping instruction would be smarter than a bit-pattern copy).
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!ttrda!levy