X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 092343858C00
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1699956677;
	bh=jJ+/bpz00lcWvSbZO9mYOrTSZAaUHMywpEJiyLXE4lM=;
	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=Au25YY7DUT7ZKFh4ONqgsKbA6wH6iUi6Q0ZnVYAY6VoJFzJxyE1BGQVvUlaytNvr3
	 p1Gix70cIE5YTNeolIPATry1hc/eisPNnnTe9h/sVOX/z7xayyveC9JKc28f/hyI4m
	 It3sy7mGIgbuw3UnIxMVlkyG5ctPtSqZNH17JL+o=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F407E3858D20
Date: Tue, 14 Nov 2023 11:11:01 +0100
To: Bruno Haible <bruno AT clisp DOT org>
Subject: Re: rand is not ISO C compliant in Cygwin
Message-ID: <ZVNHtZ+US0LFcfY3@calimero.vinschen.de>
Mail-Followup-To: Bruno Haible <bruno AT clisp DOT org>, newlib AT sourceware DOT org,
 cygwin AT cygwin DOT com
References: <9938355 DOT c9vzh5UkMf AT nimes> <ZVI06HnJE+r1CwFB AT calimero DOT vinschen DOT de>
 <ZVJM7g9smHGMN7QH AT calimero DOT vinschen DOT de> <4205183 DOT RD5H4TdPZm AT nimes>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4205183.RD5H4TdPZm@nimes>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.30
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: newlib AT sourceware DOT org
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>, 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" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

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

-- 
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