delorie.com/archives/browse.cgi | search |
X-Recipient: | archive-cygwin AT delorie DOT com |
DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org 092343858C00 |
DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; |
s=default; t=1699956677; | |
bh=jJ+/bpz00lcWvSbZO9mYOrTSZAaUHMywpEJiyLXE4lM=; | |
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=Au25YY7DUT7ZKFh4ONqgsKbA6wH6iUi6Q0ZnVYAY6VoJFzJxyE1BGQVvUlaytNvr3 | |
p1Gix70cIE5YTNeolIPATry1hc/eisPNnnTe9h/sVOX/z7xayyveC9JKc28f/hyI4m | |
It3sy7mGIgbuw3UnIxMVlkyG5ctPtSqZNH17JL+o= | |
X-Original-To: | cygwin AT cygwin DOT com |
Delivered-To: | cygwin AT cygwin DOT com |
DKIM-Filter: | OpenDKIM Filter v2.11.0 sourceware.org F407E3858D20 |
Date: | Tue, 14 Nov 2023 11:11:01 +0100 |
To: | Bruno Haible <bruno AT clisp DOT org> |
Subject: | Re: rand is not ISO C compliant in Cygwin |
Message-ID: | <ZVNHtZ+US0LFcfY3@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> <ZVI06HnJE+r1CwFB AT calimero DOT vinschen DOT de> |
<ZVJM7g9smHGMN7QH AT calimero DOT vinschen DOT de> <4205183 DOT RD5H4TdPZm AT nimes> | |
MIME-Version: | 1.0 |
In-Reply-To: | <4205183.RD5H4TdPZm@nimes> |
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 <corinna-cygwin AT cygwin 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> |
Hi Bruno, On Nov 13 22:33, Bruno Haible via Cygwin wrote: > Corinna Vinschen wrote: > > https://pubs.opengroup.org/onlinepubs/9699919799/functions/rand.html > > [...] > > 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. 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. The rational section is entirely dedicated to the base functions rand()/srand() and doesn't mention rand_r() even once. 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. > > 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". I see what you mean. 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. We have a potential patch to align rand/srand to your interpretation, at least for Cygwin if nobody else in the newlib community chimes in. It's just that, personally, I'm not yet convinced that this is the only possible interpretation. Sigh... yet another case of unnecessary vagueness in the standards... Thanks, 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
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |