Andrew Haley wrote:
>
> Yes, you can change them. Yes, they are part of an ABI. native_fd should be
> a jlong.
That's the best possible answer to our questions! Kai? I'll leave this
with you; I'm busy tracking down libffi FAILs right now.
cheers,
DaveK
On 07/19/2009 02:29 PM, Dave Korn wrote:
> Kai Tietz wrote:
>
>> There are a lot of issues about casting HANDLE values into jint types,
>> which is for x86 valid, but for x64 can lead potential to pointer
>> truncations. Those part need some review by libjava maintainers. My
>> patch simply casts
Kai Tietz wrote:
> The patch I sent here is more a head-up (and it fixes build for 32-bit
> windows builds, too).
Ok, I see the point in a headsup (but I'm not sure it was worth spending the
time to generate the patch). I take it the sole problem with the 32-bit build
is the missing natVMSecu
2009/7/19 Dave Korn :
> Kai Tietz wrote:
>> 2009/7/19 Dave Korn :
>>> Kai Tietz wrote:
>>>
There are a lot of issues about casting HANDLE values into jint types,
which is for x86 valid, but for x64 can lead potential to pointer
truncations. Those part need some review by libjava main
Kai Tietz wrote:
> 2009/7/19 Dave Korn :
>> Kai Tietz wrote:
>>
>>> There are a lot of issues about casting HANDLE values into jint types,
>>> which is for x86 valid, but for x64 can lead potential to pointer
>>> truncations. Those part need some review by libjava maintainers. My
>>> patch simply c
2009/7/19 Dave Korn :
> Kai Tietz wrote:
>
>> There are a lot of issues about casting HANDLE values into jint types,
>> which is for x86 valid, but for x64 can lead potential to pointer
>> truncations. Those part need some review by libjava maintainers. My
>> patch simply casts those kind of pointe
Kai Tietz wrote:
> There are a lot of issues about casting HANDLE values into jint types,
> which is for x86 valid, but for x64 can lead potential to pointer
> truncations. Those part need some review by libjava maintainers. My
> patch simply casts those kind of pointers via __UINTPTR_TYPE__ into
2009/7/18 Andrew Pinski :
> On Sat, Jul 18, 2009 at 12:22 PM, Kai Tietz wrote:
>> Well, uintptr_t/intptr_t are available to most (but not all hosts).
>> IIRC there is a gcc version of stdint.h (gstdint.h), which could be
>> used here. The mode version is fine too, as long as we can assume that
>> l
On Sat, Jul 18, 2009 at 12:22 PM, Kai Tietz wrote:
> Well, uintptr_t/intptr_t are available to most (but not all hosts).
> IIRC there is a gcc version of stdint.h (gstdint.h), which could be
> used here. The mode version is fine too, as long as we can assume that
> libjava isn't build by any other
2009/7/18 Dave Korn :
> Andrew Pinski wrote:
>> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>>> 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..'
>>
>> Except uintptr_t is required
Andrew Pinski wrote:
> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>> 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..'
>
> Except uintptr_t is required to be provided by a non host
2009/7/18 Andrew Pinski :
> On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
>> 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..'
>
> Except uintptr_t is required to be provided by a non
On Sat, Jul 18, 2009 at 12:08 PM, Andrew Haley wrote:
> 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..'
Except uintptr_t is required to be provided by a non hosted compiler like GCC.
-- Pins
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 ar
Kai Tietz wrote:
Oh, I forgot to address:
> I just suggested this patch, to have at least an implementation here
> for win32 for further improvement
This is the java security package. Having a vulnerable implementation is
worse IMO than having none at all; I think it would be better to just
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 n
2009/7/18 Dave Korn :
> Kai Tietz wrote:
>
>> * gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation
>> for native win32.
>>
>> Tested for x86 and x64 mingw targets. Ok for apply?
>
> + for (a = 0; a < length; a++, count++)
> + *bytes++= (jbyte) rand ();
>
> Surely n
Kai Tietz wrote:
> * gnu/java/security/jce/prng/natVMSecureRandomWin32.cc: Implementation
> for native win32.
>
> Tested for x86 and x64 mingw targets. Ok for apply?
+ for (a = 0; a < length; a++, count++)
+ *bytes++= (jbyte) rand ();
Surely not, the standard C library rand() f
2009/7/18 Dave Korn :
> Kai Tietz wrote:
>> Hello,
>>
>> I noticed, while trying to build libjava for x64 windows, that the
>> configure script fails to generate link to
>> 'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This
>> file isn't existing. Is there a fix for this?
>>
>> Th
Kai Tietz wrote:
> Hello,
>
> I noticed, while trying to build libjava for x64 windows, that the
> configure script fails to generate link to
> 'libjava/gnu/java/security/jce/prng/natVMSecureRandomWin32.cc'. This
> file isn't existing. Is there a fix for this?
>
> Thanks in advance for the answer
20 matches
Mail list logo
