RFA: libjava seems to miss some files for win32

Andrew Haley aph@redhat.com
Sat Jul 18 19:09:00 GMT 2009


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.



More information about the Java mailing list