From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id EAA08616 for <mason@werple.mira.net.au>; Wed, 3 Jul 1996 04:36:32 +1000 (EST)
Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id OAA00432; Tue, 2 Jul 1996 14:25:36 -0400 (EDT)
Resent-Date: Tue, 2 Jul 1996 14:25:36 -0400 (EDT)
From: Zefram <A.Main@dcs.warwick.ac.uk>
Message-Id: <18722.199607021824@stone.dcs.warwick.ac.uk>
Subject: Re: Sick macros (was: Action, not words (Re: bug (?) in 3.0-pre1))
To: schaefer@nbn.com
Date: Tue, 2 Jul 1996 19:24:26 +0100 (BST)
Cc: A.Main@dcs.warwick.ac.uk, hzoli@cs.elte.hu, zsh-workers@math.gatech.edu
In-Reply-To: <960702105235.ZM4305@candle.brasslantern.com> from "Bart Schaefer" at Jul 2, 96 10:52:32 am
X-Loop: zefram@dcs.warwick.ac.uk
X-Stardate: [-31]7748.83
X-US-Congress: Moronic fuckers
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Resent-Message-ID: <"9rdw23.0.g6.WcMsn"@euclid>
Resent-From: zsh-workers@math.gatech.edu
X-Mailing-List: <zsh-workers@math.gatech.edu> archive/latest/1510
X-Loop: zsh-workers@math.gatech.edu
Precedence: list
Resent-Sender: zsh-workers-request@math.gatech.edu

>And then I'd write:
>
>	HEAPALLOC {
>	    /* ... stuff ... */
>	} LASTALLOC;
>
>That makes the block context obvious.  The macros are upper-case because
>I don't like introducing new "keywords".

Yes, I think this is preferable.  As we are introducing a new block,
there should be a new indentation level for it, and the braces make it
clearer.  And there's a bonus with this syntax:

    PERMALLOC
	some_function();
    LASTALLOC;

is legal, matching other bits of C syntax.  I think the size of the
resulting patch should not be a consideration.

>} #define lastalloc_return \
>}   if( (nonlocal_useheap ? global_heapalloc() : global_permalloc()) , 0 ) \
>}     ; \
>}   else \
>}     return
>
>Hmm ... I seem to recall that some compilers don't like having void
>expressions (e.g. (?:) where both branches are void functions) used
>anywhere in a comma-expression.  In particular, I think AIX either
>rejects this or compiles it wrong.  However, I could be confusing that
>with something else ... I know for a fact that AIX could not handle
>an `if (x,y)' construct we used in zmail, forcing us to rewrite it
>as `if (x?0:y)' -- which doesn't work in general, it just happened
>that for us x was always 0 to begin with.

Curious.  It's a perfectly legal expression, so any compiler that can't
grok it is broken.  However, if a common compiler barfs on that, maybe
we could have global_{heap,perm}alloc() return 0, so the comma operator
is unnecessary and there are no void subexpressions.

>If I'm confused and the comma-expression above turns out to be OK, I'd
>change ALLOC_RESTORE and add LASTALLOC_RETURN:
>
>#define ALLOC_RESTORE \
>	    ((nonlocal_useheap ? global_heapalloc() : global_permalloc()), 0)
>#define LASTALLOC_RETURN	if (ALLOC_RESTORE); else return

Cleaner, I think, to have

#define ALLOC_RESTORE \
    ( nonlocal_useheap ? global_heapalloc() : global_permalloc() )
#define LASTALLOC_RETURN if(ALLOC_RESTORE, 0) ; else return

but the semantics of these two are identical.  ("ALLOC_RESTORE;" is a
legal statement in both cases.)

>	if (getmeoutofhere()) {
>	    ALLOC_RESTORE;
>	    return(-1);
>	}

I'd rather have the convenience of LASTALLOC_RETURN -- at least, if
this is often required.

-zefram