DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3F6C63858D32
Date: Tue, 14 Nov 2023 17:59:53 +0100
To: Bruno Haible <bruno@clisp.org>
Subject: Re: rand is not ISO C compliant in Cygwin
Message-ID: <ZVOniSk6JYImu+St@calimero.vinschen.de>
Mail-Followup-To: Bruno Haible <bruno@clisp.org>, newlib@sourceware.org,
 cygwin@cygwin.com
References: <9938355.c9vzh5UkMf@nimes> <4205183.RD5H4TdPZm@nimes>
 <ZVNHtZ+US0LFcfY3@calimero.vinschen.de> <6858244.H3tkzssBUc@nimes>
MIME-Version: 1.0
In-Reply-To: <6858244.H3tkzssBUc@nimes>
Content-Disposition: inline
Precedence: list
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: newlib@sourceware.org
Cc: Corinna Vinschen <vinschen@redhat.com>, newlib@sourceware.org,
        cygwin@cygwin.com
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>

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