This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD Editorial status.

### 504. Integer types in pseudo-random number engine requirements

Section: 28.5.3 [rand.req], 99 [tr.rand.req] Status: NAD Editorial Submitter: Walter Brown Opened: 2005-07-03 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [rand.req].

View all issues with NAD Editorial status.

Discussion:

In [tr.rand.req], Paragraph 2 states that "... s is a value of integral type, g is an ... object returning values of unsigned integral type ..."

Proposed resolution:

In 5.1.1 [tr.rand.req], Paragraph 2 replace

> ... s is a value of integral type, g is an lvalue of a type other than X that defines a zero-argument function object returning values of unsigned integral type `unsigned long int`, ...

In 5.1.1 [tr.rand.seq], Table 16, replace in the line for X(s)

> creates an engine with the initial internal state determined by `static_cast<unsigned long>(``s``)`

[ Mont Tremblant: Both s and g should be unsigned long. This should refer to the constructor signatures. Jens provided wording post Mont Tremblant. ]

[ Berlin: N1932 adopts the proposed resolution: see 26.3.1.3/1e and Table 3 row 2. Moved to Ready. ]

Rationale:

Jens: Just requiring X(unsigned long) still makes it possible for an evil library writer to also supply a X(int) that does something unexpected. The wording above requires that X(s) always performs as if X(unsigned long) would have been called. I believe that is sufficient and implements our intentions from Mont Tremblant. I see no additional use in actually requiring a X(unsigned long) signature. u.seed(s) is covered by its reference to X(s), same arguments.

[ Portland: Subsumed by N2111. ]