X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 3E8733856967
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1699911249;
	bh=KbMkfNBgNviLViY06QdNE+MfzgpLrrd6k2t5t9jPWng=;
	h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=jyS+0IHpKOllvEQp+DM6QpH1KXg1Pfb/sGKnvNLv8u10rAFubtswWkpUs3Yu0TIru
	l/33olDIy0PpNXzRERmbDOmdDpND6Gwg2ohP2lnC0EmQ6Ai7dZ1+gcttW9764U5Fc7
	Pj43G7BWxS54Bu4hOHajXuC2ZOvjmPDDupKLnL68=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org B95FE3858C41
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org B95FE3858C41
ARC-Seal:	i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1699911235; cv=pass;
	b=SXN68lTv7jNFtn33pf4Vw0I+xM7fPw0/5GjrTYmFn745FTv+vq2buI3iEgTfVIg09dW2TGfx+W5PNscmxv/NGjiB981YiJte3LwBICf477Mi1XLCgbvkEHlrBv2kLlQz/2gJTnFBu/H0f3syLdnLTdazcM08CwAn6ya0f+6oqQs=
ARC-Message-Signature:	i=2; a=rsa-sha256; d=sourceware.org; s=key;
	t=1699911235; c=relaxed/simple;
	bh=VBOAr/L+x3hvMx9TpbQTQaR13qUlljI1U4fKE0POnRg=;
	h=DKIM-Signature:DKIM-Signature:From:To:Subject:Date:Message-ID:
	MIME-Version;
	b=R9jCkhQfXYsmIP5iOee+k5v8P8Mw3pLwMAULa7ixF8wG5D71H7sehE5vFZvGK5KZdvY+9046t8qmejDobRVVOWZKowctihzBfxH1tW9wbh1Uql1twKaIEYPxoPtK8DT1IdopWAid1GuzLSe8oecP7tf1ZqA8na2HyZ8gRXzfLQw=
ARC-Authentication-Results:	i=2; server2.sourceware.org
ARC-Seal:	i=1; a=rsa-sha256; t=1699911229; cv=none;
	d=strato.com; s=strato-dkim-0002;
	b=pDaXoEA7kACHt3RErcYEkZMoiJJbAYT8Sr8p1nZikULC4hVXbOWl4JpcqAiNY2Zay9
	L1tua5FDcSCydjKkmQgZB6oL089boKKCb0gQyb9DGYoGJywu5q26hUHrEXyPi61HFva6
	T5neHDPYPnSzRJw9iWWXEnKLCQjsOABHGhv2Z+AVFEWY6bT0fSDdQ48bCJnu196idh3J
	Kc3QDz7b9pVj2Nx5vfd4CRJbebdK23RNUBv48tpszqUQYqkDZ/2Bfyi3Fl3nMS8R9YYA
	BK6YW1CX5LBB0gdPtxZS2VHQyac9WAOBrr0sV2vUFqdRd6XtTmbTSy/bXGSnkQqdzMHZ
	Zt8w==
ARC-Message-Signature:	i=1; a=rsa-sha256; c=relaxed/relaxed; t=1699911229;
	s=strato-dkim-0002; d=strato.com;
	h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From:
	Subject:Sender;
	bh=IZQVz2gnLDuRkWa1WiCXnsiouNfn7dDrahCDDqYAdOo=;
	b=PIu73lit6zOFfhYS3Jp7C9K5+jyl+JgzF6lOgvbvSEqliY2Dk2AsiBTVX3tLstxAHh
	BHxCOu86dD9p1iMB7l9uQh5R6erzaY4JKyyKUqE5p8PtK9zHhx75ghtsGlaGfUCUGIlr
	EiI+3LpnmboF707eOGgR07sE3zqrlVZf3FwZsDTSdtkeKDBaQCIbl2sBqDoFS0aNE3kl
	6VmMVSSVhW3Ex/dW6SAlGRabtJscqa1NaLfUmO7+EvJn6eA1c+b5bpN33HX4J1wuKxGX
	ctMGlceRINxo3nGIuK9iCy2O8b9W/bB/BmlWw8bZ8kbxX3WdYo4bjs2mpkrIjh0Z722h
	U9Nw==
ARC-Authentication-Results:	i=1; strato.com;
	arc=none;
	dkim=none
X-RZG-CLASS-ID:	mo00
X-RZG-AUTH:	":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPA3qFfCT9Jw/Et2No03dzxS8YHkA=="
To:	newlib AT sourceware DOT org, cygwin AT cygwin DOT com
Subject:	Re: rand is not ISO C compliant in Cygwin
Date:	Mon, 13 Nov 2023 22:33:48 +0100
Message-ID:	<4205183.RD5H4TdPZm@nimes>
In-Reply-To:	<ZVJM7g9smHGMN7QH@calimero.vinschen.de>
References:	<9938355 DOT c9vzh5UkMf AT nimes> <ZVI06HnJE+r1CwFB AT calimero DOT vinschen DOT de>
	<ZVJM7g9smHGMN7QH AT calimero DOT vinschen DOT de>
MIME-Version:	1.0
X-Spam-Status:	No, score=-3.2 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_NONE, 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-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
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:	Bruno Haible via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Bruno Haible <bruno AT clisp DOT org>
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>
X-MIME-Autoconverted:	from base64 to 8bit by delorie.com id 3ADLY9b5021929

Corinna Vinschen wrote:
> I took a look into POSIX and I'm a bit puzzled now.  From
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html

Part of the confusion is that POSIX and ISO C have slightly different
wording. This POSIX page says:
   "The functionality described on this reference page is aligned
    with the ISO C standard. Any conflict between the requirements
    described here and the ISO C standard is unintentional. This
    volume of POSIX.1-2017 defers to the ISO C standard."

In ISO C 99 § 7.20.2, the only relevant sentence is:

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

In ISO C 11 § 7.22.2 and ISO C 17 § 7.22.2, additionally two sentences
were inserted:

  "The rand function is not required to avoid data races with other
   calls to pseudo-random sequence generation functions."

  "The srand function is not required to avoid data races with other
   calls to pseudo-random sequence generation functions."

ISO C 23 (which is still is draft state, but compared to the draft
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3054.pdf I cannot
see any change regarding rand() in the changes summary
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3148.doc) has the
same wording.

POSIX does not have these two sentences, but instead has:

  "The rand() function need not be thread-safe."

> RATIONAL
> 
>   The ISO C standard rand() and srand() functions allow per-process
>                                                   ^^^^^ (not requires)
> 
>   pseudo-random streams shared by all threads.

Indeed, "requires" would fit better here, IMO, because the texts of
both ISO C and POSIX have multithreading in mind and still talk about
"subsequent calls to rand" — which makes a reference to time, but not
to threads.

> Ok, so, *iff* rand/srand share per-process state, then they have to
> use locking to prevent MT interference.

... if the implementor wants to prevent MT interference (which both
ISO C and POSIX allows).

> POSIX continues:
> 
>   With regard to rand(), there are two different behaviors that may be
>   wanted in a multi-threaded program:
> 
>   1. A single per-process sequence of pseudo-random numbers that is
>      shared by all threads that call rand()
> 
>   2. A different sequence of pseudo-random numbers for each thread that
>      calls rand()
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This paragraph continues after the two items:
   "This is provided by the modified thread-safe function based on whether
    the seed value is global to the entire process or local to each thread."

My understanding of this paragraph is:
  - If an application wants 1., they can use rand_r with SEED pointing
    to a global variable.
  - If an application wants 2., they can use rand_r with SEED pointing
    to a per-thread variable.

> I read this as the newlib technique being one way of correctly
> implementing rand/srand, no?

I don't think so. The critical sentence is the one with
"subsequent calls to rand".

Bruno




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