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: References: <9938355 DOT c9vzh5UkMf AT nimes> 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 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Bruno Haible via Cygwin Reply-To: Bruno Haible Content-Type: text/plain; charset="utf-8" Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" Content-Transfer-Encoding: 8bit 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