Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Patch available for 3.0.6-pre-0
- X-seq: zsh-workers 6088
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxx>
- To: Wayne Davison <wayne@xxxxxxxxx>
- Subject: Re: Patch available for 3.0.6-pre-0
- Date: Fri, 23 Apr 1999 21:32:08 -0700
- Cc: zsh-workers@xxxxxxxxxxxxxx
- In-reply-to: <199904212352.QAA27713@xxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <199904212352.QAA27713@xxxxxxxxxxxxxxx>
On Apr 21, 4:52pm, Wayne Davison wrote:
} Subject: Re: Patch available for 3.0.6-pre-0
}
} Some of the added braces were to enclose some one-line macros that
} consist of an "if ... else ..." block. This makes it look like some
} of the ifs have braces that are enclosing only one line.
Exactly what warning were you silencing in this case? The reason most
of those macros look like
#define thing() if (! testthing) {;} else dothing
and *not*
#define thing() if (testthing) dothing
is to prevent ambiguous/erroneous "else" situations.
My favorite approach is to write these kind of macros as
#define thing() do { if (testthing) dothing; } while (0)
because that forms a semicolon-terminable statement yet still wraps the
macro body in braces. The PERMALLOC { ... } LASTALLOC; blocks make use
of this trick, for example. However, a previous maintainer chose not to
adopt that for macros that could be written as if (...) {;} else ..., so
I'd like to have a clear reason for changing them.
--
Bart Schaefer Brass Lantern Enterprises
http://www.well.com/user/barts http://www.brasslantern.com
Messages sorted by:
Reverse Date,
Date,
Thread,
Author