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: 1108a1,9a0ff0bffdf63657
X-Google-Attributes: gid1108a1,public
X-Google-Thread: 103376,4b06f8f15f01a568
X-Google-Attributes: gid103376,public
X-Google-Thread: f43e6,9a0ff0bffdf63657
X-Google-Attributes: gidf43e6,public
From: jtc@dimensional.com (Jim Cochrane)
Subject: Re: Software landmines (loops)
Date: 1998/09/02
Message-ID: <6silt4$gb0@flatland.dimensional.com>#1/1
X-Deja-AN: 387033604
References: <slrn6sopmg.4fg.jdege@jdege.visi.com>
 <6sbuod$fra$1@hirame.wwa.com> <m3af4mq7f4.fsf@mheaney.ni.net>
 <LpVjTBAegG71EwXH@radm.demon.co.uk>
Organization: Dimensional Communications
NNTP-Posting-Date: Tue, 01 Sep 1998 23:43:08 MDT
Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada
Date: 1998-09-02T00:00:00+00:00
List-Id: <comp.lang.ada>

In article <LpVjTBAegG71EwXH@radm.demon.co.uk>,
Richard Melvin  <rmelvin@radm.demon.co.uk> wrote:
>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.

It appears that this routine has an implied pre-condition:
l.size() == r.size()

In this case, if l is empty, r is also empty.  I think you can easily
define equality as including the case where both stacks are empty.  I
suppose you could say that the problem is an undocumented pre-condition.

>
>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.

I think, more appropriately, it argues for the "Document routine
pre/post-conditions (as well as use assertions as documentation of
program state, where appropriate)" 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


-- 
Jim Cochrane
jtc@dimensional.com