From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=iUC1=GX=huarp.harvard.edu=allen@sourceware.org>
Received: from endymion.arp.harvard.edu (mercury.arp.harvard.edu [140.247.179.71])
	by sourceware.org (Postfix) with ESMTPS id ECE2D3858D1E
	for <cygwin@cygwin.com>; Fri, 10 Nov 2023 21:39:44 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org ECE2D3858D1E
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=huarp.harvard.edu
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=huarp.harvard.edu
ARC-Filter: OpenARC Filter v1.0.0 sourceware.org ECE2D3858D1E
Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=140.247.179.71
ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699652386; cv=none;
	b=GsypI+37mufaysE9zt4axPzbum7kX5Nh5XMjX61tzUCYCZtHiYS1IFEqx5xd/bRM067pqAuVkpUAR+DXh5oXlP1xCKJyTSwcq7DDn/EOE9EHRwGdvgYSU67/0h0A59WUsncveINTrt5GT+IjhvSzHB6HgRCnkzD5otmK/QGcT2M=
ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1699652386; c=relaxed/simple;
	bh=FFAVbcdLSerujUhPmvnODtUu1GIeFPYmke4hWN5cvvE=;
	h=Message-ID:Date:MIME-Version:Subject:To:From; b=AZqxTXXfPbIeiKhgpqNW6yVZ1k4Gr67qkcVPGM7fGzF6VAS/WFRu2I9yr8/nD3OaIqozE3LO9w68HoVFLacQETeSubPw6uvXR/vlCqo5akOmNtuo4gVvoA9c7y6zZwSaYXElgpBjJ6FFfrLI4X27Whs0OzP7xavoeR8LPEEK8Es=
ARC-Authentication-Results: i=1; server2.sourceware.org
Received: from [192.168.7.107] (pool-71-184-121-244.bstnma.fios.verizon.net [71.184.121.244])
	(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
	 key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
	(No client certificate requested)
	by endymion.arp.harvard.edu (Postfix) with ESMTPSA id 75CF8261628;
	Fri, 10 Nov 2023 16:39:44 -0500 (EST)
Message-ID: <e099714b-9820-4647-ba40-9db5e471e9aa@huarp.harvard.edu>
Date: Fri, 10 Nov 2023 16:39:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: rand is not ISO C compliant in Cygwin
Content-Language: en-US
To: Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com
References: <9938355.c9vzh5UkMf@nimes>
From: Norton Allen <allen@huarp.harvard.edu>
In-Reply-To: <9938355.c9vzh5UkMf@nimes>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,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
List-Id: <cygwin.cygwin.com>

On 11/10/2023 3:19 PM, Bruno Haible via Cygwin wrote:
> ISO C 23 § 7.24.2.1 and 7.24.2.2 document how rand() and srand() are
> expected to behave. In particular:
>    "The srand function uses the argument as a seed for a new sequence
>     of pseudo-random numbers to be returned by subsequent calls to rand.
>     If srand is then called with the same seed value, the sequence of
>     pseudo-random numbers shall be repeated. ...
>     The srand function is not required to avoid data races with other
>     calls to pseudo-random sequence generation functions. ..."
>
> The two attached programs call srand() in one thread and then rand()
> in another thread. There is no data race, since the second thread
> is only created after the call to srand() has returned. The behaviour
> in Cygwin is that the values in the second thread ignore the srand()
> call done in the first thread.

Since the standard is trying to be precise, this reads to me as though 
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.


>
> How to reproduce the bug:
>
> $ x86_64-pc-cygwin-gcc -Wall rand-in-posix-thread.c
> $ ./a
>
> or
>
> $ x86_64-pc-cygwin-gcc -Wall rand-in-isoc-thread.c
> $ ./a
>
> Expected output:
>
> Value from main thread:     1583559764
> Value from separate thread: 1583559764
>
> Actual output:
>
> Value from main thread:     1583559764
> Value from separate thread: 1481765933
>
>