🚀 go-pugleaf

lloyd!wse@husc6.harvard.edu (Bill Edwards) writes:

>Let's say I have a pointer to a 'struct foo' which I have typedef'ed to
>FOOPTR.  If I then do something like:

>	FOOPTR foo_ptr = (FOOPTR) malloc ((unsigned) sizeof (struct foo));

>at the start of a function, lint on a Sun 4 (SPARC) complains that this
>line has " possible pointer alignment problems" (lint does *not* give me
>this meesage on a Sun 3).  I wrote a short program to do a sizeof of
>'struct foo'.  On the Sun 3, 'struct foo' has a size which is not
>divisible by 4, but on the Sun 4 its size *is* divisible by 4 (has
>evidently been padded to a long-word boundary).  So, my question is, how
>do I placate lint in this instance?  How do I align the pointer?  I've
>tried ensuring that I only malloc memory in chunks in multiple of 4
sizes, >but to no avail.

Here is how I have dealt with this problem; it is probably not the
correct way, but everything has worked so far.

I have replaced the above call to malloc() with my own routine getbuf().
getbuf() calls malloc(), but first insures that the requested size is a
multiple of the word size.  This is just to make sure that subsequent
calls to malloc() retain the alignment.  getbuf() then verifies that the
pointer returned by malloc() is aligned on a word boundary.  If not, it
just exits with a message, but this has never happened and everything has
worked fine (SUN 3's & 4's).  Note that lint still complains, but who
cares.

Recently I ported some software that uses this onto the center's CRAY
(where the word size is 64 bits).  The program promptly died with the
message "getbuf:  not a word boundary."  I considered rounding the request
up by WORDSIZE-1, and then selecting a pointer aligned on a word boundary
by masking off the lower order bits, but this is no good since the pointer
returned by getbuf() must be one that you can hand back to free().  So I
handled it by malloc'ing the number of bytes to make the next call to be
aligned, then forgetting the returned pointer and trying again.  The idea
is that this isn't going to happen too many times (hopefully only the
first time).  In the worst case you throw away 7 bytes.

I look forward to seeing a more elegant solution.

	Jeff Mulligan (jbm@aurora.arc.nasa.gov)
	NASA/Ames Research Ctr., Mail Stop 239-3, Moffet Field CA, 94035
	(415) 694-3745