On 07/18/2009 07:27 PM, Dave Korn wrote: > Kai Tietz wrote: > >> Yes, I agree to this as I said in the patch post. Can we assume that >> any win32 target has a working wincrypt.h file? > > Hmmm... it is supported since win2k. I imagine DGJPP runs on 9x targets, > and believe it or not there are still some Cygwin users on NT4. I would think > it needs an autoconf test, and on platforms that don't support CryptoAPI it > should probably throw an exception to indicate 'not implemented' rather than > (e.g.) fall back to rand(), but that's a policy decision for the Java > maintainers really.
Either this is a cryptographically strong random number or it must throw NotImplemented. >> I just suggested this patch, to have at least an implementation here >> for win32 for further improvement (Btw I missed in my initial patch to >> include explicit <stdlib.h> here, too). >> I am just running through libjava for an initial port for x64 windows. >> There are a lot of assumptions about sizeof (long) == sizeof (void*), >> but the worse thing I see is the casting of HANDLE values to jint. For >> x86 this is fine, but for x64 this can lead to serious troubles. > > Ouch, yes! You'll probably be best off replacing those with something based > on uintptr_t, which may or may not have a j* equivalent already. Don't use uintptr_t, use unsigned int __attribute__((mode(PTR)). This is built-in to gcc, not a dependency on the host libc which might not be c99.. Andrew.
