From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 2155) id F407E3858D20; Tue, 14 Nov 2023 10:11:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F407E3858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1699956663; bh=QjJ0Sk7COgBL8om+VUTJYLAQA1Nzb2nWriU3U9zxAeI=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=HySpJQXH+L2nOgBL2w2KUyACZu0wCmfyddoBLwvYi/hvr2VcOhhMp3QteamweUCTz Npd+H4praEdV5zkYEtxep+VzzE12h5PImhl3Iv+sr6L8vypYUUU+K4quksGQAj+lBK cnw76XhH4evdz63ThSLVH4Kef6bea2chNMDxmA/Q= Received: by calimero.vinschen.de (Postfix, from userid 500) id 2CE9FA80A38; Tue, 14 Nov 2023 11:11:01 +0100 (CET) Date: Tue, 14 Nov 2023 11:11:01 +0100 From: Corinna Vinschen To: Bruno Haible Cc: newlib@sourceware.org, cygwin@cygwin.com Subject: Re: rand is not ISO C compliant in Cygwin Message-ID: Reply-To: newlib@sourceware.org Mail-Followup-To: Bruno Haible , newlib@sourceware.org, cygwin@cygwin.com References: <9938355.c9vzh5UkMf@nimes> <4205183.RD5H4TdPZm@nimes> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <4205183.RD5H4TdPZm@nimes> List-Id: 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