X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.3.2 sourceware.org CA4833857823
Authentication-Results:	sourceware.org; dmarc=none (p=none dis=none)
	header.from=SystematicSw.ab.ca
Authentication-Results:	sourceware.org;
	spf=none smtp.mailfrom=brian DOT inglis AT systematicsw DOT ab DOT ca
X-Authority-Analysis:	v=2.3 cv=OubUNx3t c=1 sm=1 tr=0
	a=kiZT5GMN3KAWqtYcXc+/4Q==:117 a=kiZT5GMN3KAWqtYcXc+/4Q==:17
	a=IkcTkHD0fZMA:10 a=_ctWjzdLAAAA:8 a=RZ24vCjvlsqmbDxLIRQA:9
	a=JO7Pc56EJyraQzXB:21 a=zXw3yNnIoF1UuWCE:21 a=QEXdDO2ut3YA:10
	a=WoGCsytTnHKj16XvecxK:22
Subject:	Re: cygwin qsort erratic
To:	cygwin AT cygwin DOT com
References:	<CAHybJinLYpcviSFiJ=V-EZqoatEzjFfr9DOUzxzmofUmtwMS+w AT mail DOT gmail DOT com>
	<c9792fdc-aedc-6934-e11f-732f841b533b AT SystematicSw DOT ab DOT ca>
	<CAHybJi=+uKitmwhWfuc564xz6qxZF+H=rA87LaB1NBJPkBAsUA AT mail DOT gmail DOT com>
	<1464bc69-4dd5-b63d-d1b9-048b52fe036e AT towo DOT net>
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Autocrypt:	addr=Brian DOT Inglis AT SystematicSw DOT ab DOT ca; prefer-encrypt=mutual;
	keydata=
	mDMEXopx8xYJKwYBBAHaRw8BAQdAnCK0qv/xwUCCZQoA9BHRYpstERrspfT0NkUWQVuoePa0
	LkJyaWFuIEluZ2xpcyA8QnJpYW4uSW5nbGlzQFN5c3RlbWF0aWNTdy5hYi5jYT6IlgQTFggA
	PhYhBMM5/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsDBQkJZgGABQsJCAcCBhUKCQgLAgQW
	AgMBAh4BAheAAAoJEB62lxu92I8Y0ioBAI8xrggNxziAVmr+Xm6nnyjoujMqWcq3oEhlYGAO
	WacZAQDFtdDx2koSVSoOmfaOyRTbIWSf9/Cjai29060fsmdsDLg4BF6KcfMSCisGAQQBl1UB
	BQEBB0Awv8kHI2PaEgViDqzbnoe8B9KMHoBZLS92HdC7ZPh8HQMBCAeIfgQYFggAJhYhBMM5
	/lbU970GBS2bZB62lxu92I8YBQJeinHzAhsMBQkJZgGAAAoJEB62lxu92I8YZwUBAJw/74rF
	IyaSsGI7ewCdCy88Lce/kdwX7zGwid+f8NZ3AQC/ezTFFi5obXnyMxZJN464nPXiggtT9gN5
	RSyTY8X+AQ==
Organization:	Systematic Software
Message-ID:	<dd9d0748-4113-1b88-866c-abcb123e7f27@SystematicSw.ab.ca>
Date:	Mon, 31 Aug 2020 12:50:08 -0600
User-Agent:	Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
	Thunderbird/68.12.0
MIME-Version:	1.0
In-Reply-To:	<1464bc69-4dd5-b63d-d1b9-048b52fe036e@towo.net>
X-CMAE-Envelope:	MS4wfE/Nqht9VCdDgV5fe49lL/OY7tsYSyuqXs3SqCS5xS3AQ1CQMfa3Ea/5mPZyABFkqKb/zwpG6sMmA8EYRKfBi2/vd0KE9ZHxIv4TqlsZT2lO0+Q3TDe6
	qGu7VtfhxbDJbIfECApcSsv8QfGzSBTqp+Ji9p/IqT2WjR1GXZ3jaFAySIRBBph87FAeaWxBCezTPw==
X-Spam-Status:	No, score=-8.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
	KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2,
	SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
Reply-To:	cygwin AT cygwin DOT com
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>

On 2020-08-31 12:00, Thomas Wolff wrote:
> Am 31.08.2020 um 19:50 schrieb Kurt-Karen Carlson-Lougheed via Cygwin:
>> On Sun, Aug 30, 2020 at 7:55 PM Brian Inglis wrote:
>>> On 2020-08-30 15:27, Kurt-Karen Carlson-Lougheed via Cygwin wrote:
>>>> In a small percentage of qsort requests, the results are erratic. Running
>>>> the same code under Linux (RHEL7) does NOT have this problem. I updated
>>> my
>>>> cygwin to current and the problem persists. I copied the latest
>>> netbsd.org
>>>> qsort.c and compiled into my code, the problem is resolved with that
>>>> version of qsort.
>>>>
>>>> In researching this issue, there was a post to this list 2015-01-11
>>>> reporting a
>>>> 'damaged' qsort. This may still be the same issue. The netbsd version I
>>> am
>>>> now using is dated 2017-05-19.
>>>>
>>>> My code experiencing this is SourceForge uac19, I'll be posting the
>>>> corrected version (v3.2) with the netbsd qsort tomorrow after completing
>>>> validation tests. I would ultimately like to see cygwin's qsort fixed.

>>> As qsort depends on the array object data types and comparison
>>> functions, please post a Simple Test Case, showing at least those types
>>> and function(s), and the faulty output results.
>> Corinna,
>> I'm a cygwin user and neither a cygwin nor netbsd developer. I do not know
>> what newlib or 'git format-patch' are. If I had access to source for
>> cygwin's qsort  I could probably devise a patch, but it's probably better
>> for somebody familiar with the tools cygwin uses to do that. The attached
>> qqsort.h is an easy geek read. That qsort works with Linux/RHEL7 and with
>> netbsd's version under cygwin should make fixing it straight forward for
>> somebody in the know.

>> Brian,
>> It's difficult to produce a simple test case with erratic behavior. I have
>> wrapped my qsort invocations within a qqsort routine. I've attached
>> qqsort.h which includes both the wrapper and the netbad qsort.c renamed as
>> Qsort (and with _DIAGASSERT's commented out). Also attached is cygsort.txt
>> which is script output demonstrating the problem. My apologies that is 200+
>> lines, the Verbose mode states whether Qsort (netbsd) or qsort (cygwin) is
>> being invoked, I added the '$' command to toggle back and forth. Descending
>> sorts on the D/C (dpc) column have been most problematic. The descending
>> '+S dpc' after the ascending '+s dpc' is the most graphic example. I did
>> publish uac19 v3.3 on SourceForge this morning, or I can send somebody a
>> tgz.

> Kurt-Karen, this is hard to comprehend. It is common practice that someone who
> claims something is buggy, especially about something essential like qsort,
> should demonstrate that claim with a reproducible test case, even if, as you
> say, it may be difficult to produce one. If this happens in a series of
> invocations you have it should be possible to identify one case with wrong
> results and reproduce its input and invocation scenario.

You attached the qsort source, which is already in Cygwin, but did not include
your input csv data, data structures, data reading, and qsort comparison
functions, which would allow us to try to reproduce the issue.
We need your raw input and output data, and the core sorting code, to do so.

The simplest approach is to use the sort utility to sort your input data to
produce the expected output, and compare that to the equivalent output generated
from your sort program.
If you added that capability to your code, and did that on every run, you could
capture the problem input and output data when diff returned non-zero status.

Most sort problems are from premature optimization: trying to be too efficient
in comparison functions, which then don't do exactly as expected in all the
input data cases: you create a heisenbug, which you then need to detect and
reproduce.
Often, making the comparison function code as simple and straightforward as
possible, and ensuring it will always give exactly the expected result,
eliminates the issue. First make it correct, then make it fast!

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in IEC units and prefixes, physical quantities in SI.]
--
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple

- Raw text -