Re: rand is not ISO C compliant in Cygwin

[Bruno Haible <bruno@clisp.org>]

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.

Bruno