rand is not ISO C compliant in Cygwin

[Corinna Vinschen]

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