Re: RFA: libjava seems to miss some files for win32

Andrew Haley <[email protected]>
Newsgroups gmane.comp.gcc.devel,gmane.comp.gcc.java.devel
Message-ID <[email protected]>
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.