X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org E640D38582BD
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1699981236;
	bh=Mmsn1cjP4/jF6q5FMV8OJdRwYpj3N1G06Jf1dCpqrCM=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	From;
	b=o8AIkLMGlsaFmc13iy8eZAh7Ci3+bV0kkTJtAkgzY3j31FbtTGeE+2ocn0/loDtDI
	ioIWfZILhDS7pvRZYRHsd0cDtRcC8hplPhzu63y6gUmDxDsgF+n4E0T7N4WmVC1fim
	cG+LZJv8I8OmcsCpFgQKWy3Ler5KMKSDLKs52qw4=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 3F6C63858D32
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 3F6C63858D32
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1699981198; cv=none;
	b=le/xNDkFQ9wzTyVAJ4SneANdss3/Yjm00TMI7j6JuEBy83lrHIQiCk9FZrvhy7Vu37R6qXQP2trBuM3XzQcTp6Sc2WZlNEdgQU3BXYBF2T862mZgCuCC1b2n3Lt6aklGnZwDxCrs7c6uXYm8BqyjC70ZBfAQXdBMVmneX3/XQjc=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1699981198; c=relaxed/simple;
	bh=sKaIlyyU5wMKjqZQr9PBKYQTixkQMZaymBJmSp/Q3XU=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=hvYRcONzVqlI7A70KA314Pnmk+IfRoZItNDsFAzf2dKW0tgY3k/ZzaVKoFrgCoopVsPJ0GMwTQmPLL6wfkzKvKkb5xplc8o0ZE+tKGRT/pxtGAGMDL3M0xcc2m1kRIpI7rFRq0rv+jVw/S/OHQnx9srqgFB+G1bk4PnbtsmAUGA=
ARC-Authentication-Results:	i=1; server2.sourceware.org
X-MC-Unique:	-jQUT8SbNpOaFtB9qfrScw-1
Date:	Tue, 14 Nov 2023 17:59:53 +0100
To:	Bruno Haible <bruno AT clisp DOT org>
Subject:	Re: rand is not ISO C compliant in Cygwin
Message-ID:	<ZVOniSk6JYImu+St@calimero.vinschen.de>
Mail-Followup-To:	Bruno Haible <bruno AT clisp DOT org>, newlib AT sourceware DOT org,
	cygwin AT cygwin DOT com
References:	<9938355 DOT c9vzh5UkMf AT nimes> <4205183 DOT RD5H4TdPZm AT nimes>
	<ZVNHtZ+US0LFcfY3 AT calimero DOT vinschen DOT de> <6858244 DOT H3tkzssBUc AT nimes>
MIME-Version:	1.0
In-Reply-To:	<6858244.H3tkzssBUc@nimes>
X-Scanned-By:	MIMEDefang 3.4.1 on 10.11.54.6
X-Mimecast-Spam-Score:	0
X-Mimecast-Originator:	redhat.com
X-Spam-Status:	No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH,
	DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE,
	RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, 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:	Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	newlib AT sourceware DOT org
Cc:	Corinna Vinschen <vinschen AT redhat DOT com>, newlib AT sourceware DOT org,
	cygwin AT cygwin DOT com
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>

On Nov 14 12:52, Bruno Haible wrote:
> Corinna Vinschen wrote:
> > > 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.
> > 
> > The problem I have with bringing rand_r() into the picture at this point
> > is two-fold:
> > 
> > - The paragraph explicitely states "With regard to rand() ..."
> > 
> > - rand_r() is obsolescent and may be removed in a future version.
> 
> This paragraph is not directed at the libc implementor; it is directed at
> the application programmer. Because
>   - Otherwise the phrase "may be wanted in a multi-threaded program"
>     would not make sense.
>   - The goals "1. A single per-process sequence of pseudo-random numbers"
>     and "2. A different sequence of pseudo-random numbers for each thread"
>     cannot be achieved at the same time, since rand() takes no argument.
> 
> > I don't see that the vague expression "the modified thread-safe function"
> > is really meant to be rand_r(), or rather rand() after an implementation decides
> > to make rand() thread-safe.
> 
> It must mean rand_r(), because rand() cannot satisfy both goals at the
> same time.
> 
> > However, what sense is there in providing a global
> > state, while at the same time rand() doesn't need to be thread-safe.  In
> > the end, if you call srand() once and then run rand() in concurrent
> > threads, the implementation has no control over the sequences generated
> > per-thread, unless your application threads will sync the calls explicitely.
> 
> The sense is reproducibility across threads. The standards comittee
> probably wanted as little thread-specific verbiage at this place.
> 
> The two sentences added in ISO C 11 mean that the application needs to
> sync their threads by itself, yes. But that's not uncommon: Every use of,
> say, a global linked-list or hash table object accessed by multiple threads
> needs the same precaution.

Ok, I pushed a Cygwin-only patch for now, which calls Cygwin's random(3)
functions to implement rand(3), just as GLibC does it.

Since that's entirely inside the Cygwin codebase, other newlib targets
are not affected right now.  They still have a rand(3) PRNG per execution
unit using either struct _reent, or the thread_local implementation.


Corinna


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