From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mo4-p00-ob.smtp.rzone.de (mo4-p00-ob.smtp.rzone.de [85.215.255.21]) by sourceware.org (Postfix) with ESMTPS id B95FE3858C41 for ; Mon, 13 Nov 2023 21:33:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B95FE3858C41 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=clisp.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B95FE3858C41 Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=85.215.255.21 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1699911229; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=IZQVz2gnLDuRkWa1WiCXnsiouNfn7dDrahCDDqYAdOo=; b=GNJ88PLweepHV/erd2gApwe2wWLeMSjobXcwAUR6hEVF7JINKQ4jWb7oP0JBSfVQvd NQ8+qszC2sXDEpHXhd8M4Xs56ecvjMGWlHR+E9A54lcBCSFh/1crbKKCjSe/COKRIQ0O 5ltPL00j6dhPtY95BZctykayGByIy8ZXFFAt8H+evck+hcsmceQpkz0YG3SMVpkjFL5I JUcsdJKkohqMYn7DqJOoh5rb3uJ+DEWcwnrd1j4/0Cd+6J2zTr8XDTyc3I75lVRY8nHB ct4ga0DRUCehL62vzn1euWrhJw3wEp/HeEOBk01XaJB7YIx0ig8U10MiDNZYgk+DfKIL eBWw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; t=1699911229; s=strato-dkim-0003; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:To:From:Cc:Date:From: Subject:Sender; bh=IZQVz2gnLDuRkWa1WiCXnsiouNfn7dDrahCDDqYAdOo=; b=Ktb/OUuDaWB/vK0JLcz47U/eKUy/zfPRo267Uc6cQgVEuLfQ+XX7Ehk4xWA6y3OLoj EPOkOwsr9MOiX9doohAQ== X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH0WWb0LN8XZoH94zq68+3cfpPA3qFfCT9Jw/Et2No03dzxS8YHkA==" Received: from nimes.localnet by smtp.strato.de (RZmta 49.9.1 AUTH) with ESMTPSA id D75765zADLXn3TX (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits)) (Client did not present a certificate); Mon, 13 Nov 2023 22:33:49 +0100 (CET) From: Bruno Haible To: newlib@sourceware.org, cygwin@cygwin.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.c9vzh5UkMf@nimes> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" 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 List-Id: 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 =C2=A7 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 =C2=A7 7.22.2 and ISO C 17 =C2=A7 7.22.2, additionally two sent= ences 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 >=20 > The ISO C standard rand() and srand() functions allow per-process > ^^^^^ (not requires) >=20 > 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" =E2=80=94 which makes a reference to time, but n= ot to threads. > Ok, so, *iff* rand/srand share per-process state, then they have to > use locking to prevent MT interference. =2E.. if the implementor wants to prevent MT interference (which both ISO C and POSIX allows). > POSIX continues: >=20 > With regard to rand(), there are two different behaviors that may be > wanted in a multi-threaded program: >=20 > 1. A single per-process sequence of pseudo-random numbers that is > shared by all threads that call rand() >=20 > 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