From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3658 invoked from network); 24 Apr 1999 07:13:05 -0000 Received: from ns2.primenet.com.au (HELO primenet.com.au) (203.24.36.3) by ns1.primenet.com.au with SMTP; 24 Apr 1999 07:13:05 -0000 Received: (qmail 5602 invoked from network); 24 Apr 1999 07:12:36 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns2.primenet.com.au with SMTP; 24 Apr 1999 07:12:36 -0000 Received: (qmail 11796 invoked by alias); 24 Apr 1999 07:12:28 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6090 Received: (qmail 11789 invoked from network); 24 Apr 1999 07:12:27 -0000 From: Wayne Davison Message-Id: <199904240712.AAA14094@bebop.clari.net> To: "Bart Schaefer" Cc: zsh-workers@sunsite.auc.dk In-reply-to: schaefer's message of Fri, 23 Apr 1999 21:32:08 -0700. <990423213208.ZM25952@candle.brasslantern.com> Subject: Re: Patch available for 3.0.6-pre-0 Date: Sat, 24 Apr 1999 00:12:22 -0700 Sender: wayne@clari.net "Bart Schaefer" writes: > Exactly what warning were you silencing in this case? The "ambiguous else" warning. A brace-less "if" that has an "if" macro after it gets turned into "if (...) if (...) ... else ...", which causes the warning. My solution was to add the braces to the calling "if", which turns it into "if (...) { if (...) ... else ... }". > 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. Yeah, I'm familiar with the dangers of adding such else-less ifs via a macro. My statement was mainly meant to explain why some ifs that are followed by a single line needed braces added to them (since it would be easy for you to look at what I'd done and think that I was just not following the current coding style). I personally don't think that we need to change the macros for the release of 3.0.6, but I figured I'd mention it in case you felt otherwise. Long term, I think that we should consolidate all the multi-line macros into a single style that avoids ambiguous-else warnings, but that work may not affect the 3.0.* code base. I also agree with you that the "do { ... } while (0)" style is one of the best when a macro includes multiple lines of code (since I personally dislike omitting semi-colons from the macro references). I hadn't noticed that this was used in the code -- I just saw some defines being called without semi-colons, and I assumed that that was the zsh style. ..wayne..