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 Subject: Re: rand is not ISO C compliant in Cygwin Message-ID: Mail-Followup-To: Bruno Haible , newlib AT sourceware DOT org, cygwin AT cygwin DOT com References: <9938355 DOT c9vzh5UkMf AT nimes> <4205183 DOT RD5H4TdPZm AT nimes> <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 Content-Disposition: inline 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 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: newlib AT sourceware DOT org Cc: Corinna Vinschen , newlib AT sourceware DOT org, cygwin AT cygwin DOT com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com Sender: "Cygwin" 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