On Mon, Jul 17, 2000 at 02:05:32AM -0700, Greg Stein wrote:
> On Mon, Jul 17, 2000 at 09:55:02AM +0200, M.-A. Lemburg wrote:
> > and it produces warnings which relate to the fact that the "else"
> > part is ambiguous:
> >
> > if (condition) UTF8_ERROR();
> > else {...}
> >
> > expands to:
> >
> > if (condition)
> > if (1) {...}
> > else ;
> > else {...}
>
> That is not ambiguous.
Nope. The example was flawed. *this* is ambiguous:
if (condition) UTF8_ERROR();
And that's exactly what gcc is whining about:
if (s + n > e)
UTF8_ERROR("unexpected end of data");
It's very clearly defined what happens, here, but gcc can't see the macro as
is, and mis-placing 'else's is a very common error. Especially combined with
macros :) In absense of a standard-defined error-reporting tool, gcc -Wall
does a very good job. And don't start about lint, the versions of lint I've
seen were much more picky ;)
> > The goto solution is much cleaner and also easier to understand.
> Arguable.
Even more arguable is the coding style issue ;) I haven't seen this 'if (1)
{} else' trick used in macros elsewhere, not in Python and not in other
code. Granted, those pieces of code didn't need to call continue, but I
personally prefer the goto over the weird macro.
--
Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4