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.
cheers,
DaveK
