X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F3F7F3875460
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1699721449;
	bh=7R3P6/nE7Tz8vihZ/GmIRlZZI0knP4TS+QPMtM2ZDew=;
	h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	 From;
	b=CUKmLAzWk7vXxTsaZVsGYWTbAPpqwU/73TLT0kajmcmTmemuHB1blMiT94Jk1u7MD
	 yg6aOijVx3lO2RhTHkN5RD+Rybc45tNDhbFOosKAis52K3ORDuUP3gJyQtJ6kbFXVd
	 1Sa0V2zldjHR0RzrxakPXQEd7D6+rTW4mkkyGZ8g=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 081853858039
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 081853858039
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699721436; cv=none;
 b=wDPAdGR+zTgpEL16kbG66akvsueA7H0AnDLWsjmd7ipdwzOqYcSUu+FZjZAU/LfFz7wXzw1SsmWu1wh92uPWUg8U26A4xIEbbsQ/cJGlDjrvIYQS4u2Jul//0y4k07ZG8eNnuTtXIt4bkDoqoXHO89bBCe56UVpa6a/ASskrEYE=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
 t=1699721436; c=relaxed/simple;
 bh=KQASpEg/F98KlkLbOnuORedkBxqCVIBOtr6dFelmMOQ=;
 h=Message-ID:Date:MIME-Version:Subject:To:From;
 b=m5O4CnXI67HY3woHwB8/Hq+4P4ZSXvRKzB+tKPJNwQpSulNQ3a6Z1v8DE4oO1GwVZvfvW7WLO0n4HpPg/nrHcCR9l0WVCQDPmootQl6YqdIT8XY0aPJHq4JLWprD3W9xsN4+0FaTXss2CkN9oqHT+kB9PC51m25DgoPKzdV6e2A=
ARC-Authentication-Results: i=1; server2.sourceware.org
Message-ID: <cec7bb32-1a34-4c3c-8b8b-175d998003ef@huarp.harvard.edu>
Date: Sat, 11 Nov 2023 11:50:30 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: rand is not ISO C compliant in Cygwin
To: Bruno Haible <bruno AT clisp DOT org>, cygwin AT cygwin DOT com
References: <9938355 DOT c9vzh5UkMf AT nimes>
 <e099714b-9820-4647-ba40-9db5e471e9aa AT huarp DOT harvard DOT edu>
 <5748524 DOT yeFs27NDWt AT nimes>
Content-Language: en-US
In-Reply-To: <5748524.yeFs27NDWt@nimes>
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00, HTML_MESSAGE,
 KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.30
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
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>
From: "Allen, Norton T. via Cygwin" <cygwin AT cygwin DOT com>
Reply-To: "Allen, Norton T." <allen AT huarp DOT harvard DOT edu>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 3ABGoo3Q020506

On 11/10/2023 5:27 PM, Bruno Haible wrote:
> Norton Allen wrote:
>> Cygwin/(newlib?) has chosen to avoid race conditions by making
>> pseudo-random sequences in different threads independent. Although the
>> standard does not require this, it does not prohibit it either.
> I disagree. I cited the relevant sentences from the standard.

This is the sentence you quoted that I am referring to:

> The srand function is not required to avoid data races with other
>     calls to pseudo-random sequence generation functions. ..." 
That is not the same as "... required never to avoid data races ...". 
"not required" means the sentence is not specifying--not requiring--any 
behavior, so you should not depend on the described behaviors.

>
> Other platforms (glibc, Android) avoid race conditions in rand()
> by locking. Which is compliant with the standard.

I'm not sure I understand what you're saying. Do they require the caller 
to implement their own race-avoidance approach via locking, or is it 
implemented within rand()?

As you point out, there is no race condition here, but it looks to me as 
though the Cygwin strategy chooses to avoid race conditions by making 
the rand() state be entirely private to each thread. As a result, the 
call in rand_invocator_thread() acts as though no call to srand() has 
occurred. You are suggesting that the thread should inherit the rand 
state from the parent, which would certainly make the threads subject to 
race conditions, even if the calls themselves were thread-safe. Which 
value your thread gets would depend on how fast it ran relative to the 
other threads. Unless there is language in the standard that says the 
states should be shared, I don't see how the Cygwin approach violates 
the standard.

That said, I am often wrong, and I'd be happy to have you point out my 
misunderstanding.

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