Hi,

The recommended way seems to get one number from
std::random_device.  However, to open the device is
expensive.  To allocate a std::seed_seq is also expensive.
std::time(0) is cheap, but it subscribe to linear dependency.
I imagine if there is a cheap and good-enough seed-generator,
which returns an unspecified type which is implicitly convertible
to any unsigned integral type.  So that we can:

  std::default_random_engine e{ std::make_seed() };

A possible underlying implementation might be to use
an rdtsc intrinsic:

  http://www.mcs.anl.gov/~kazutomo/rdtsc.html

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_240_8953764.1377835072456
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, August 29, 2013 1:15:34 PM UTC-7, Zhihao Yuan wrote:
>
> Hi,
>
> The recommended way seems to get one number from
> std::random_device.  However, to open the device is
> expensive.  To allocate a std::seed_seq is also expensive.
> std::time(0) is cheap, but it subscribe to linear dependency.
> I imagine if there is a cheap and good-enough seed-generator,
> which returns an unspecified type which is implicitly convertible
> to any unsigned integral type.


What is "good-enough"? For many uses, `std::time(0)` is "good-enough". If
you have specific needs for your seed generation algorithm, then I would
say that there's no general-purpose solution for that. And if you don't
have specific needs, the old standby of `std::time(0)` or the like ought to
be sufficient.

At the very least, can you explain how `std::make_seed` would be specified
in terms of standard-ese? Can it be specified such that `return
std::time(0)` would *not* be a valid implementation?

Furthermore, seeding an RNG is generally an initialization-time step. So is
it really that bad that it could be "expensive"? Furthermore, even if we
did have such a thing, that would not prevent `std::make_seed`
implementations from being "expensive" if an implementation choose to make
them so.

So that we can:
>
>   std::default_random_engine e{ std::make_seed() };
>
> A possible underlying implementation might be to use
> an rdtsc intrinsic:
>
>   http://www.mcs.anl.gov/~kazutomo/rdtsc.html
>

Wouldn't that have the "linear dependency" that you feel is bad about
`std::time(0)`? Or if "linear dependency" of this type is acceptable to
you, just use `std::high_resolution_clock`.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_240_8953764.1377835072456
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, August 29, 2013 1:15:34 PM UTC-7, Zhihao Yuan=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>The recommended way seems to get one number from
<br>std::random_device. &nbsp;However, to open the device is
<br>expensive. &nbsp;To allocate a std::seed_seq is also expensive.
<br>std::time(0) is cheap, but it subscribe to linear dependency.
<br>I imagine if there is a cheap and good-enough seed-generator,
<br>which returns an unspecified type which is implicitly convertible
<br>to any unsigned integral type.</blockquote><div><br>What is "good-enoug=
h"? For many uses, `std::time(0)` is "good-enough". If you have specific ne=
eds for your seed generation algorithm, then I would say that there's no ge=
neral-purpose solution for that. And if you don't have specific needs, the =
old standby of `std::time(0)` or the like ought to be sufficient.<br><br>At=
 the very least, can you explain how `std::make_seed` would be specified in=
 terms of standard-ese? Can it be specified such that `return std::time(0)`=
 would <i>not</i> be a valid implementation?<br><br>Furthermore, seeding an=
 RNG is generally an initialization-time step. So is it really that bad tha=
t it could be "expensive"? Furthermore, even if we did have such a thing, t=
hat would not prevent `std::make_seed` implementations from being "expensiv=
e" if an implementation choose to make them so.<br><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;">So that we can:
<br>
<br>&nbsp; std::default_random_engine e{ std::make_seed() };
<br>
<br>A possible underlying implementation might be to use
<br>an rdtsc intrinsic:
<br>
<br>&nbsp; <a href=3D"http://www.mcs.anl.gov/~kazutomo/rdtsc.html" target=
=3D"_blank">http://www.mcs.anl.gov/~<wbr>kazutomo/rdtsc.html</a>
<br>
</blockquote><div><br>Wouldn't that have the "linear dependency" that you f=
eel is bad about `std::time(0)`? Or if "linear dependency" of this type is =
acceptable to you, just use `std::high_resolution_clock`.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_240_8953764.1377835072456--

.

On Thu, Aug 29, 2013 at 11:57 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> What is "good-enough"? For many uses, `std::time(0)` is "good-enough".

I agree it should be sufficient in practice.  Just, considering it
already killed 1/3 possible values in a 32-bit range, I personally
don't like that very much.

BTW, although it's a library function, it requires a system call,
which makes it slow.

> At the very least, can you explain how `std::make_seed` would be specified
> in terms of standard-ese? Can it be specified such that `return
> std::time(0)` would not be a valid implementation?

`return std::time(0)` should be regarded as a valid implementation for
now.  Invalid after 94 years of course :)

> Wouldn't that have the "linear dependency" that you feel is bad about
> `std::time(0)`?

As you can see, Rdtsc is much better since there is no mathematical
relationship between different runs; if the initial value is unpredictable
in one execution, the succeeding values are also unpredictable.

> Or if "linear dependency" of this type is acceptable to you, just use
> `std::high_resolution_clock`.

`high_resolution_clock` may depends on time-since-boot.
In that case, it gives a very small possible value range.

Well, I'm not professional on this topic; let me cc W.E. Brown.

My point is very simple: we should have a function to get a
`seed`, not time or something.  std::time(0), Rdtsc, RdRand,
etc., those are implementation details, and we should not ask
programmers to manually use them.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_383_7540350.1377840794280
Content-Type: text/plain; charset=ISO-8859-1



On Friday, August 30, 2013 4:15:34 AM UTC+8, Zhihao Yuan wrote:
>
> Hi,
>
> The recommended way seems to get one number from
> std::random_device.  However, to open the device is
> expensive.


That is the *interface* which the Standard defines to access your
platform's random number facilities. It provides for multiple, named
facilities, but makes no requirements of their mathematical or temporal
performance, except to say that it may just be a pseudorandom sequence for
a machine with no genuine entropy.

If you want your platform to perform differently, contact the vendor.

A possible underlying implementation might be to use
> an rdtsc intrinsic:
>

That's a fine suggestion for your library vendor, but this forum is not
concerned with hardware implementations.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_383_7540350.1377840794280
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 30, 2013 4:15:34 AM UTC+8, Zhiha=
o Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>The recommended way seems to get one number from
<br>std::random_device. &nbsp;However, to open the device is
<br>expensive.</blockquote><div><br>That is the <i>interface</i> which the =
Standard defines to access your platform's random number facilities. It pro=
vides for multiple, named facilities, but makes no requirements of their ma=
thematical or temporal performance, except to say that it may just be a pse=
udorandom sequence for a machine with no genuine entropy.<br><br>If you wan=
t your platform to perform differently, contact the vendor.<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"> A possible underlying implement=
ation might be to use
<br>an rdtsc intrinsic:
<br></blockquote><div><br>That's a fine suggestion for your library vendor,=
 but this forum is not concerned with hardware implementations. <br></div><=
/div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_383_7540350.1377840794280--

.

On Fri, Aug 30, 2013 at 1:33 AM, David Krauss <potswa@gmail.com> wrote:
>> A possible underlying implementation might be to use
>> an rdtsc intrinsic:
>
> That's a fine suggestion for your library vendor, but this forum is not
> concerned with hardware implementations.

random_device is a perfect source of seeding in a
mathematical sense, but a seed generator does not need
to meet all the requirements which a random number generator
has -- obviously, seeding has no distribution requirement.
Due to this, random_device is usually slow and gives
us too much.  That is why I want a seed generator with a
weaker requirement, so that it can be implemented in a much
cheaper way.  Last but not least, from the point of view of the
interface, `make_seed()` is conceptually cleaner and easier
to use then `random_device{}()`.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_270_6671193.1377844472266
Content-Type: text/plain; charset=ISO-8859-1



On Friday, August 30, 2013 1:50:00 PM UTC+8, Zhihao Yuan wrote:
>
> random_device is a perfect source of seeding in a
> mathematical sense,


No, random_device is whatever your platform defines it to be. The standard
makes no guarantees on its mathematical behavior.

Perhaps the language could standardize that std::random_device( "seed" )should have useful behavior for seeding a PRNG. But there
*is nothing more to be done at the language level* and you need to take
this up with your library vendor.

Last but not least, from the point of view of the
> interface, `make_seed()` is conceptually cleaner and easier
> to use then `random_device{}()`.
>

That's subjective. Is it better to provide one name for each ultimate
use-case, or to avoid bloated complexity and stick to one name for the
fundamental functionality of obtaining physical entropy? If make_seed is
defined it should certainly for the sake of uniformity just forward to
something like std::random_device( "seed" ), which then also needs to be
reserved to the standard.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_270_6671193.1377844472266
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 30, 2013 1:50:00 PM UTC+8, Zhiha=
o Yuan wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">random_device is =
a perfect source of seeding in a
<br>mathematical sense,</blockquote><div><br>No, <span style=3D"font-family=
: courier new,monospace;">random_device</span> is whatever your platform de=
fines it to be. The standard makes no guarantees on its mathematical behavi=
or.<br><br>Perhaps the language could standardize that <span style=3D"font-=
family: courier new,monospace;">std::random_device( "seed" )</span> should =
have useful behavior for seeding a PRNG. But there <i>is nothing more to be=
 done at the language level</i> and you need to take this up with your libr=
ary vendor.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> Last=
 but not least, from the point of view of the
<br>interface, `make_seed()` is conceptually cleaner and easier
<br>to use then `random_device{}()`.<br></blockquote><div><br>That's subjec=
tive. Is it better to provide one name for each ultimate use-case, or to av=
oid bloated complexity and stick to one name for the fundamental functional=
ity of obtaining physical entropy? If <span style=3D"font-family: courier n=
ew,monospace;">make_seed</span> is defined it should certainly for the sake=
 of uniformity just forward to something like <span style=3D"font-family: c=
ourier new,monospace;">std::random_device( "seed" )</span>, which then also=
 needs to be reserved to the standard.</div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_270_6671193.1377844472266--

.

------=_Part_411_9121723.1377850582810
Content-Type: text/plain; charset=ISO-8859-1

On Thursday, August 29, 2013 11:34:32 PM UTC-7, David Krauss wrote:
>
> On Friday, August 30, 2013 1:50:00 PM UTC+8, Zhihao Yuan wrote:
>>
>> random_device is a perfect source of seeding in a
>> mathematical sense,
>
>
> No, random_device is whatever your platform defines it to be. The
> standard makes no guarantees on its mathematical behavior.
>
> Perhaps the language could standardize that std::random_device( "seed" )should have useful behavior for seeding a PRNG. But there
> *is nothing more to be done at the language level* and you need to take
> this up with your library vendor.
>
> Last but not least, from the point of view of the
>> interface, `make_seed()` is conceptually cleaner and easier
>> to use then `random_device{}()`.
>>
>
> That's subjective.
>

Not really. If there is to be a standardized generator for seeds, why would
a user expect the class `random_device` to provide this functionality? Yes,
`random_device` provides numbers that are legitimate values for seeding
RNGs, but that is *not* why the class exists. It would be surprising to a
user that `random_device("seed")` would produce something specially
designed for seeds.

Granted, I see no point in having a standardized generator for RNG seeds at
all. But if we're going to have one, it needs to be as simple and intuitive
to use as possible. And overloading `random_device` for this is neither of
those.

New functionality should require a new function.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_411_9121723.1377850582810
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, August 29, 2013 11:34:32 PM UTC-7, David Krau=
ss wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">On F=
riday, August 30, 2013 1:50:00 PM UTC+8, Zhihao Yuan wrote:<blockquote clas=
s=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc =
solid;padding-left:1ex">random_device is a perfect source of seeding in a
<br>mathematical sense,</blockquote><div><br>No, <span style=3D"font-family=
:courier new,monospace">random_device</span> is whatever your platform defi=
nes it to be. The standard makes no guarantees on its mathematical behavior=
..<br><br>Perhaps the language could standardize that <span style=3D"font-fa=
mily:courier new,monospace">std::random_device( "seed" )</span> should have=
 useful behavior for seeding a PRNG. But there <i>is nothing more to be don=
e at the language level</i> and you need to take this up with your library =
vendor.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"> Last but not =
least, from the point of view of the
<br>interface, `make_seed()` is conceptually cleaner and easier
<br>to use then `random_device{}()`.<br></blockquote><div><br>That's subjec=
tive.</div></div></blockquote><div><br>Not really. If there is to be a stan=
dardized generator for seeds, why would a user expect the class `random_dev=
ice` to provide this functionality? Yes, `random_device` provides numbers t=
hat are legitimate values for seeding RNGs, but that is <i>not</i> why the =
class exists. It would be surprising to a user that `random_device("seed")`=
 would produce something specially designed for seeds.<br><br>Granted, I se=
e no point in having a standardized generator for RNG seeds at all. But if =
we're going to have one, it needs to be as simple and intuitive to use as p=
ossible. And overloading `random_device` for this is neither of those.<br><=
br>New functionality should require a new function.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_411_9121723.1377850582810--

.

On Fri, Aug 30, 2013 at 6:54 AM, Zhihao Yuan <zy@miator.net> wrote:
> On Thu, Aug 29, 2013 at 11:57 PM, Nicol Bolas <jmckesson@gmail.com> wrote=
:
>> What is "good-enough"? For many uses, `std::time(0)` is "good-enough".
>
> I agree it should be sufficient in practice.  Just, considering it
> already killed 1/3 possible values in a 32-bit range, I personally
> don't like that very much.
>
> BTW, although it's a library function, it requires a system call,
> which makes it slow.
>
>> At the very least, can you explain how `std::make_seed` would be specifi=
ed
>> in terms of standard-ese? Can it be specified such that `return
>> std::time(0)` would not be a valid implementation?
>
> `return std::time(0)` should be regarded as a valid implementation for
> now.  Invalid after 94 years of course :)

What happens after 94 years? AFAIK the encoding of `time_t` is
unspecified. (And I don't know any encoding that fails in 2117)

Mit freundlichen Gr=FC=DFen,

Martinho

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Fri, Aug 30, 2013 at 2:34 AM, David Krauss <potswa@gmail.com> wrote:
>> random_device is a perfect source of seeding in a
>> mathematical sense,
>
>
> No, random_device is whatever your platform defines it to be. The standard
> makes no guarantees on its mathematical behavior.

Ahh, yes, you are right.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Fri, Aug 30, 2013 at 8:06 AM, Martinho Fernandes
wrote:
>> `return std::time(0)` should be regarded as a valid implementation for
>> now.  Invalid after 94 years of course :)
>
> What happens after 94 years? AFAIK the encoding of `time_t` is
> unspecified. (And I don't know any encoding that fails in 2117)

time_t is either 32-bit or 64-bit on UNIX, which represents seconds
from UNIX epoch.  But, the default type of some URNGs are
uint32_fast_t, thus the remaining value range can only serve
until 2107.

One more problem: two pseudo random number generator
with the same algorithm and seeded with the same number
will generate exactly the same sequence.  So afaics an
ideal seed generator should always return different
values for each calls during a program's lifetime.  And
`std::time(0)` has only 1 second granularity, which is bad.

random_device has no such guarantee but I don't know
whether we want the requirement to be that precise.

As you can see, there are too many details if a programmer
digs into the implementation of a seed generator.
I think the better way is to starts with an abstraction,
like `make_seed`.

--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_614_2266270.1377870111409
Content-Type: text/plain; charset=ISO-8859-1



On Friday, August 30, 2013 8:06:31 PM UTC+8, R. Martinho Fernandes wrote:
>
> What happens after 94 years? AFAIK the encoding of `time_t` is
> unspecified. (And I don't know any encoding that fails in 2117)
>

Unsigned 32-bit time_t overflow. But usually it is signed, and overflow
isn't a particular issue as long as it keeps going up.

The real problem is that if two PRNGs are both seeded in this way in the
same second, they will follow the same sequence. For example, two threads
might need independent PRNGs because such stateful objects aren't
thread-safe. Then an attacker can record values from the two sequences,
match them up, and predict the future values of one sequence. Even without
such a benefit, an attacker with some idea of your server uptime can make a
good guess at the initial seed.

The problem with a CPU cycle counter is that it's really not portable
enough. x86 and PowerPC have it, but those are two of the most baroque
architectures in common use. The standard mentions that random_device might
not have access to real entropy, and that would have to apply to a seed
function as well.

You could use std::high_resolution_clock, which is likely to map to such an
intrinsic as linked above, but could be anything.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_614_2266270.1377870111409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Friday, August 30, 2013 8:06:31 PM UTC+8, R. Ma=
rtinho Fernandes wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">What ha=
ppens after 94 years? AFAIK the encoding of `time_t` is
<br>unspecified. (And I don't know any encoding that fails in 2117)
<br></blockquote><div><br>Unsigned 32-bit time_t overflow. But usually it i=
s signed, and overflow isn't a particular issue as long as it keeps going u=
p.<br><br>The real problem is that if two PRNGs are both seeded in this way=
 in the same second, they will follow the same sequence. For example, two t=
hreads might need independent PRNGs because such stateful objects aren't th=
read-safe. Then an attacker can record values from the two sequences, match=
 them up, and predict the future values of one sequence. Even without such =
a benefit, an attacker with some idea of your server uptime can make a good=
 guess at the initial seed.<br><br>The problem with a CPU cycle counter is =
that it's really not portable enough. x86 and PowerPC have it, but those ar=
e two of the most baroque architectures in common use. The standard mention=
s that random_device might not have access to real entropy, and that would =
have to apply to a seed function as well.<br><br>You could use std::high_re=
solution_clock, which is likely to map to such an intrinsic as linked above=
, but could be anything.<br></div></div>

<p></p>

-- <br />
&nbsp;<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_614_2266270.1377870111409--

.