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

[Bruce Evans]

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

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.

Bruce