-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Brian Paul wrote:
> Robert Noland wrote:
>> Build was broken by commit 9666529b5a5be1fcde82caadc2fe2efa5ea81e49
>>
>> I'm not certain that this is entirely the correct fix since the demo
>> from bug #23774 seemed to work before the commit that broke the build.
>>
>> Signed-off-by: Robert Noland <rnol...@2hip.net>
>> ---
>> src/glx/x11/glxhash.c | 7 +++++++
>> 1 files changed, 7 insertions(+), 0 deletions(-)
>>
>> diff --git a/src/glx/x11/glxhash.c b/src/glx/x11/glxhash.c
>> index 7d28ada..dcf8c98 100644
>> --- a/src/glx/x11/glxhash.c
>> +++ b/src/glx/x11/glxhash.c
>> @@ -87,6 +87,12 @@
>>
>> #define HASH_ALLOC malloc
>> #define HASH_FREE free
>> +#ifndef __GLIBC__
According to the manual page, _SVID_SOURCE || _BSD_SOURCE is required
for initstate_r and friends. The non-_r versions require _SVID_SOURCE
|| _BSD_SOURCE || _XOPEN_SOURCE >= 500. Specifically, it says:
Feature Test Macro Requirements for glibc (see feature_test_macros(7)):
random_r(), srandom_r(), initstate_r(), setstate_r(): _SVID_SOURCE ||
_BSD_SOURCE
Does that mean that you have to use (__GLIBC__ && (_SVID_SOURCE ||
_BSD_SOURCE)), or does it mean that just using (_SVID_SOURCE ||
_BSD_SOURCE) is sufficient? I guess the other alternative is to have
some autoconf mechanism to test for those functions. That's probably
the right answer anyway.
The non-_r versions don't fix the bug. The bug was that the hash
functions modified the global random number state.
>> +#define HASH_RANDOM_DECL char *ps, rs[256]
>> +#define HASH_RANDOM_INIT(seed) ps = initstate(seed, rs, sizeof(rs))
>> +#define HASH_RANDOM random()
>> +#define HASH_RANDOM_DESTROY setstate(ps)
>> +#else
>> #define HASH_RANDOM_DECL struct random_data rd; int32_t rv; char
>> rs[256]
>> #define HASH_RANDOM_INIT(seed) \
>> do { \
>> @@ -95,6 +101,7 @@
>> } while(0)
>> #define HASH_RANDOM ((void) random_r(&rd, &rv), rv)
>> #define HASH_RANDOM_DESTROY
>> +#endif
>>
>> typedef struct __glxHashBucket
>> {
>
> I was just looking at this after my coworker found the build failure on
> MacOS.
>
> Would nrand48() be a more portable option? Ian?
>
> See http://evanjones.ca/random-thread-safe.html
nrand48 may be thread-safe, but it still brings back the bug.
I guess we can use feature test macros to select the _r functions on
platforms that support it, and we can let the bug continue to exist on
platforms that leave no (reasonable) alternative.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkq5M54ACgkQX1gOwKyEAw8aEQCgkYH9x9mvStfpx9AFJbEN9lDm
powAoIqN4zG1H1+SfWozGa4X121WjWL7
=FYL2
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
