2009/7/19 Dave Korn <dave.korn.cyg...@googlemail.com>:
> Kai Tietz wrote:
>> 2009/7/19 Dave Korn <dave.korn.cyg...@googlemail.com>:
>>> 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
>>>> integer scalar before casting it into jint. I put comments at those
>>>> places, where some rework is necessary.
>>> Argh. You're replacing a bunch of warnings that draw attention to a real
>>> problem by a bunch of silent fixmes in the code. That's a bit scary to me.
>>
>> Right, therefore those comments are for. But otherwise I couldn't get
>> it build, as those kind of failures are treated as errors (what is in
>> fact a good thing).
>
> Yes, so since they are a good thing, you should *not* get rid of them. It
> is better for it not to build than for it to silently build bad code. If you
> want it to work, you should make it *actually* work, otherwise just add it to
> noconfigdirs until such time as you can make it work. There is not only no
> point successfully building a broken library, there is _less_ than no point.
>
> Whenever adding fixmes, you must plan on there being a very great likelihood
> of them getting forgotten and never fixed. Rule #1 of maintenance-friendly
> coding.
>
>>> Question is, can we change the sizes of the members of class objects, such
>>> as gnu::java::net::PlainSocketImpl::native_fd, or do these objects and their
>>> layout form part of an ABI, and/or do they ever get serialised? The Java
>>> guys
>>> will be able to tell us.
>
>> This was the reason, why I didn't changed api here. The final patch I
>> see here done by the java team, as I have no real idea, if those types
>> and members are part of abi, here. If it is there are ways to solve
>> this (e.g. making abstract handle values for OS handles as example).
>> So it is for sure necessary that a java maintainer takes action here.
>
> I fail to see the value of building a broken libjava for w64. It's not a
> step you need to get past on the roadmap to making a working java for w64.
> Just don't build it at all. --disable-libjava or $noconfigdirs.
>
> Alternatively, wait a few hours until the java guys have a chance to
> respond. Maybe we can just change the datatypes, after all. But I really
> can't see any use and only harm in adding a silently broken implementation.
Well, in standard I agree. But in this special case is the code just
broken for apps using more then 32-bit address range for heap (and
handles). Btw a run of testsuite works here in pretty much cases.
The patch I sent here is more a head-up (and it fixes build for 32-bit
windows builds, too). If I keep stuff in my back-chamber, things won't
improve and nobody knows that there is an issue present.
Cheers,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
