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:

<1464bc69-4dd5-b63d-d1b9-048b52fe036e AT towo DOT net> From: Brian Inglis 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: 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> Content-Language: en-CA 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 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: cygwin AT cygwin DOT com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces AT cygwin DOT com Sender: "Cygwin" 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