On Wed, Sep 14, 2005 at 01:05:50PM -0600, Shaun Jackman wrote: > 2005/9/14, Michael Koch <[EMAIL PROTECTED]>: > > You replace jint (which is garanteed to be 32 bit) with long which dont has > > this garantee. > > Why dont you just build the native sources that upstream supplies for 64 > > bit systems? > > That is what I do in the eclipse build works very fine. BTW: My Eclipse > > packages are ready > > to replace your SWT. When you give me your okay I can imidiately upload it > > to the archive > > (via some sponsor). I think this would be the easiest solution at all. > > I realise that long is not guaranteed to be 32-bit. In fact, that's > the very reason I'm using it, so that on 64-bit platforms it will be > wide enough to cast a pointer to long. The negative consequence of > changing (jint) to (long) is that on 64-bit architectures the pointer > will be cast to a 64-bit long, and then silently cast down to a 32-bit > jint. This second step is potentially lossy on a system that uses > addresses greater than 2^32 (4 GB). Although potentially hazardous, > this is how the package has been behaving with GCC 3 for some time. > So, I don't believe this patch is a regression, but merely returning > the package to status quo. > > If it's possible to patch one source tree to work on all > architectures, I prefer that solution to using one source tree per > architecture, which quickly gets out of hand.
I just dont get why you wanna patch when upstream has already did the work for you and made SWT work on both types of platforms. And changing jint to long can cause bugs that are really hard to debug. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
