out-of-line and arch-specific random_device

[Paolo Carlini]

Hi,

On 8/28/12 1:41 PM, Ulrich Drepper wrote:
> On Tue, Aug 28, 2012 at 4:44 AM, Paolo Carlini<paolo.carlini@oracle.com>  wrote:
>> Again, without context, I think this is not the point: random_device is meant to be just a simple high level wrapper
>> around things like dev/random, inspired by facilities like dev/random on unix-like OSes. The brutal "fall back" we have
>> now in place wouldn't be useful anyway for the uses Marc is talking about, because there is no way to provide a seed.
>> That said, I can't check right now C++11 about random_device, I suppose Uli has already ;)
> I did read it.  random_device is all about non-determinism.  Of course
> I know that RNGs in some situations have to be repeatable.  That's
> what all the engines are about.  random_device isn't.  You use
> random_device to seed an engine etc.
>
> The spec says that if there is no way to create non-deterministic data
> the implementation may use a random number engine.  "may" being to
> key.
Ok.
> I perhaps didn't make myself clear as to what the big problem is.
> Depending on whether or not you define _GLIBCXX_USE_RANDOM_TR1 you get
> an object definition for 'random"device" which has the same name and
> mangling but has a different size.  This means binary
> incompatibilities.  Memory corruptions.
But note that _GLIBCXX_USE_RANDOM_TR1, as *any* other such macro isn't 
supposed to be set by the user, definitely it's not. It's a 
configure-time macro. Thus, given your clarification above about "may", 
I think the issue here is whether normally people would like to see an 
abort, or the output of a fixed (no seed, that is, as we clarified 
already) deterministic engine as a fall back. In my opinion, having 
clarified the macro uses issue, the less bad solution is the 
deterministic engine. As a general maintainer of the library (that is 
not as a GNU/Linux maintainer) I would be more favorable to the abort if 
we had decently covered not just Unix-like systems but a few other 
systems, at least a bit of M$, etc.

Thus, all in all, I propose to just go ahead with your patch more or 
less, as-is, that is retain the MT fall back. Minor nit: are you sure we 
need to open a new minor version for the new symbol? Because it seemed 
to me that 4.7.x was behind by one. Please check. Also, again minor 
detail, we normally just use mangled names in the linker script, see all 
the examples the lines before, I don't think we should just now change 
that?!?

Paolo.