bug#11604: USE_LISP_UNION_TYPE + USE_LSB_TAG cleanup.

[Paul Eggert]

On 06/02/2012 12:31 AM, Eli Zaretskii wrote:
> why did you change DECL_ALIGN to DCL_ALIGN?

A typo.  It didn't prevent compilation on my platform.  Thanks for
pointing it out; the revised patch will fix this.

>> +    (union Lisp_Object): Don't worry about WORDS_BIGENDIAN; the
>> +    code works fine either way, and efficiency is not a concern here.
>
> why isn't efficiency a concern?

Because the union type is for debugging, not for production.
It's used mostly to make sure that (for example) one doesn't
mistakenly write "x = y" when one meant to write "x = XINT (y)".
I'll reword the ChangeLog entry to make it clearer.

>> +    (LISP_MAKE_RVALUE, make_number) [USE_LISP_UNION_TYPE]:
>> +    Use an inline function on all platforms, since this is simpler and
>> +    'static inline' (via gnulib) is portable now.
>
> I still see one instance of LISP_MAKE_RVALUE as a macro in lisp.h:

The ChangeLog entry is only about the USE_LISP_UNION_TYPE case, not
the case you noticed.  I'll reword this for clarity.

> Also, which parts of gnulib make 'static inline' portable?  If it
> isn't in a part that is used by the MS-Windows port, the MSVC build is
> still being screwed by these changes.

Mostly, it's the AC_C_INLINE stuff in m4/*.  'static inline' been used
for some time in Emacs, and it works just fine with the MSVC build.
I'll reword the ChangeLog entry to remove the distracting mention of
gnulib.

> The following changes are not mentioned in the log entry:

They are mentioned here:

        (XSET) [USE_LISP_UNION_TYPE]: Don't overparenthesize.

> What was the reason for removing this comment:

Please see Bug#11617, which I just now filed.  I will restore that
comment in the revised patch, as it's now an independent issue.