svn commit: r206424 - head/usr.bin/xlint/lint1

[Roman Divacky]

On Sun, Apr 11, 2010 at 07:16:12PM +1000, Bruce Evans wrote:
> On Fri, 9 Apr 2010, Roman Divacky wrote:
> 
> >Log:
> > Rename the ALIGN macro to LINT_ALIGN so it does not clash with 
> > machine/param.h
> >
> > Bump the alignment to 16bytes because lint1 memory allocator is used for
> > objects that require 16bytes alignment on amd64 (ie. val_t). This makes
> > lint1 work when compiled with compiler(s) that use SSE for memcpy on 
> > amd64.
> > (e.g. clang).
> 
> This seems to be mostly backwards.  xlint wants to use the system
> ALIGN(), since it has no way of knowing the correct alignment.  However,
> the system might not supply ALIGN(), so it provided its own
> probably-incorrect ALIGN() as a fallback.  FreeBSD has a system ALIGN()
> and it should have always been used.  xlint get the includes correct
> for this, though this is fragile.  However2, the system ALIGN() on
> amd64 doesn't know the correct alignment either (both essentially had
> 64 bits hard-coded).  Now xlint uses a different hard-coded alignment
> (128 bits).
 
so you suggest fixing the ALIGN on amd64? ie. to make it 128bit?

> For a non-backwards fix, you need to follow the comment in xlint which
> says ALIGN should go away [in xlint].  Other compilers might need a
> working system ALIGN() in other places.  I think only memory allocator
> in xlint needs a working ALIGN() (just 1 instance).  Perhaps the allocator
> should just use malloc().  The only other uses of ALIGN() are in getbound().
> These seem to be all completely wrong.  The all use ALIGN(1), where ALIGN()
> is the host or hard-coded ALIGN() which gives maximal alignment and 1 is
> the size of a char, where SALIGN(type), where SALIGN() is the source
> ALIGN() which gives the (usually non-maximal) alignment of a type and
> the `type' parameter must contain type info and not be just the size of
> the type (certainly not the size of another type) since types of the same
> size may have different alignment.  SALIGN() is much more impossible to
> write as a portable macro.

the xlint allocator uses malloc and builds upon it. fixing this wont be
trivial and I have no interest in it :(