Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: stdcxx-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45EDBD60.5050200@roguewave.com>
Date: Tue, 06 Mar 2007 12:13:36 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1
MIME-Version: 1.0
To: stdcxx-dev@incubator.apache.org
Subject: Re: --compat mode behavior issues
References: <45E4BA90.5090602@roguewave.com> <45EA0CAB.1070901@roguewave.com>
 <45ED9EF5.1060203@roguewave.com> <45EDA508.2040706@roguewave.com>
 <45EDAA15.8000601@roguewave.com> <45EDB071.4050501@roguewave.com>
 <45EDB740.6090502@roguewave.com>
In-Reply-To: <45EDB740.6090502@roguewave.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Andrew Black wrote:
> One probable reason is that some legacy tests (like 27_iosfile) produce 
> multiple assertion totals (or are supposed to), and we want the last of 
> these, rather than the first.

To handle this case we should process the file from the beginning
and take the last total as the final one.

> A second possible reason was to make the 
> parsing FSM slightly simpler (though adding an additional character or 
> two to the pattern shouldn't make it much more complex).

I don't think avoiding the seek would add too much complexity
(the default non-compat case doesn't seek and it's no more
complex than the compat mode).

> A final 
> possible reason was to make the parsing faster for long output files.

If the common case is the default mode (i.e., not --compat)
we optimized the wrong branch :) In any case, getting correct
results slowly is better than getting the wrong results fast.

I suggest you rewrite check_compat_test() to avoid seeking
and scan the whole file, top to bottom, and take the last
total.

Martin