From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: fac41,9a0ff0bffdf63657
X-Google-Attributes: gidfac41,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
X-Google-Thread: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
From: Richard Melvin <rmelvin@radm.demon.co.uk>
Subject: Re: Software landmines (loops)
Date: 1998/09/01
Message-ID: <LpVjTBAegG71EwXH@radm.demon.co.uk>#1/1
X-Deja-AN: 386928006
Distribution: world
X-NNTP-Posting-Host: radm.demon.co.uk:194.222.155.111
References: <slrn6sopmg.4fg.jdege@jdege.visi.com>
 <rfzpddz3s2.fsf@bnp-eng.remcomp.com>
 <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <dewar.903074236@merv>
 <6r1glm$bvh$1@nnrp1.dejanews.com> <dewar.903281994@merv>
 <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com>
 <6rf59b$2ud$1@nnrp1.dejanews.com> <l5HC1.6840$wN.1856764@news.giganews.com>
 <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk>
 <m3ogt3qgca.fsf@mheaney.ni.net> <6sbuod$fra$1@hirame.wwa.com>
 <m3af4mq7f4.fsf@mheaney.ni.net> <904556531.666222@miso.it.uq.edu.au>
 <m31zpxqutn.fsf@mheaney.ni.net> <6sf87j$47n$1@hirame.wwa.com>
X-Complaints-To: abuse@demon.net
X-Trace: news.demon.co.uk 904687978 nnrp-03:28256 NO-IDENT
 radm.demon.co.uk:194.222.155.111
Organization: n/a
MIME-Version: 1.0
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-01T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <6sf87j$47n$1@hirame.wwa.com>, Robert Martin
<rmartin@oma.com> writes
>bool operator==(Stack& l, Stack& r)
>{
>  bool equal = true;
>  for (int index = 1; index < l.top() && equal == true; index++)
>  {
>    if (l[index] != r[index])
>      equal = false;
>  }
>  return equal;
>}

Now, following convoluted conditionals[1] like the above always makes my
head spin, but it looks to me like the above code would always return
true when comparing against an empty stack.

Given that this is a trivial piece of code, written by an expert, read
by half of usenet, and nobody seems to have spotted the problem, I think
this has to count as a significant data point on the side of the
multiple returns camp.

Richard

[1] It's not particularly complicated, but it does combine into one
expression two tests with completely different purposes, which I think
is always a source of confusion. Of course, the 1-based indexing doesn't
help, with 0-based being more usual in C++ - this is probably a second
bug, but I'd have to see the specification of top and operator[] to find
out.
 
-- 
Richard Melvin