Re: base64 suggestions
>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)srce.hr> writes:
Hrvoje> Martin Buchholz <martin(a)xemacs.org> writes:
> The Sun compiler points out that this code looks suspicious:
>
> if (decoded_length < 0)
> {
> return Qnil;
> XMALLOC_UNBIND (decoded, length * MAX_EMCHAR_LEN);
> }
Hrvoje> And rightfully so. Fix attached below.
> Also, here is a rewritten XMALLOC_OR_ALLOCA macro that avoids
> multiple evaluation of the `len' argument.
Hrvoje> I'll add the patch on the grounds of general saneness, but what's the
Hrvoje> point? I mean, the macro is purely local in nature, and if you use
Hrvoje> it, you should know what you're doing.
For macros that have statement semantics, e.g. using do {} while (0),
as opposed to expression semantics, it is always possible to eliminate
multiple evaluation, and we should do so consistently. I have been
adding this kind of macro hygiene in the XEmacs sources for a while now.
Hrvoje> Your rewritten version also adds parentheses around PTR, which is an
Hrvoje> lvalue -- is that legal? (I removed them.)
You can put redundant parens around any expression, including lvalues.
The general rule of thumb is that one should always put parens around
any macro argument.
In the particular case of
ptr = expression
the extra parens in fact can not make a difference, so
XMALLOC_OR_ALLOCA is safe as Hrvoje claims, but only because of the
quirk in C that an assignment expression is not an lvalue, and you
cannot pass a non-parenthesized comma expression as a macro argument.
Martin