Bug 245192

Ew, the Inventor code is _utterly_ broken. It's casting pointers to int. The
patch below should make it no more broken on PPC64 than it is on x86_64, but
it's still broken. We should stop shipping it on both x86_64 and ppc64 until
it's properly fixed.

inventor/lib/database/include/Inventor/SbPList.h.orig       2007-06-23
05:45:18.000000000 -0400
+++ inventor/lib/database/include/Inventor/SbPList.h    2007-06-23
05:45:41.000000000 -0400
@@ -195,7 +195,7 @@ SoINTERNAL class SbIntList : public SbPL
        { ((SbPList *) this)->insert((void *) (unsigned long) integer, addBefore); }
 
     int &      operator [](int i) const
-#if (_MIPS_SZPTR==64) && (_MIPS_SZINT==32)
+#ifdef __powerpc64__
        // An ugly cast that makes sure that when we cast from void* to
        // int&, we get the rightmost four bytes, rather than the upper
        // bytes.  

(In reply to comment #1)
> Ew, the Inventor code is _utterly_ broken. It's casting pointers to int.
SbPList is an associative map, mapping int->pointers.

The trick they apply is using the least significant bits of an address as key
into a map. This works unless a the least significant bits of an address match
to those of another. Though this isn't a clean approach, in practice, these
occasions rarely apply in Inventor.

> The
> patch below should make it no more broken on PPC64 than it is on x86_64,
Shouldn't this #ifdef distingiush between BIG/LITTLE endian platforms?

> but
> it's still broken.
Right, it's a hack and should be addressed.

> We should stop shipping it on both x86_64 and ppc64 until
> it's properly fixed.
If we'd react such kind of harsh for any such kind of issues, there would not be
much to ship.

(In reply to comment #2)
> The trick they apply is using the least significant bits of an address as key
> into a map. This works unless a the least significant bits of an address match
> to those of another. Though this isn't a clean approach, in practice, these
> occasions rarely apply in Inventor.

Ick.

> Shouldn't this #ifdef distingiush between BIG/LITTLE endian platforms?

Well yes, but it's a crappy hack just to demonstrate the problem. The correct
response is to _fix_ it.
 
> > We should stop shipping it on both x86_64 and ppc64 until
> > it's properly fixed.
> If we'd react such kind of harsh for any such kind of issues, there would not be
> much to ship.

I very strongly disagree. It takes some effort to write code this bad; we
certainly don't ship much that's this crappy. It should be fixed, or dropped.

You should make a better hash function than  'x & 0xffffffff', but the patch in
comment #1 ought to make ppc64 at least no more broken than x86_64. Does it work?

It worked until gcc-4.3.0.

gcc4.3.0's strict-aliasing kills it once again on ppc64.

Correction: ... kills it on x86_64 (!)

Methinks it deserved to die :)

(In reply to comment #7)
> Methinks it deserved to die :)
If you are referring to the defects in C++'s standards related to aliasing, and
GCC's poor powerpc backend, then I would agree.

Should you be referring to the ppc, I would also agree - Linux on ppc's are a
dying species not worth to be taken care about by a mainstream distro.

Wrt. Inventor, I am working on it ;)

No, I'm referring to the Inventor code.

If you are aware of any problems with the compiler's PowerPC backend which are
causing difficulty for Fedora packages, please make sure they are brought to my
attention. I am not aware of any current issues, and the PowerPC toolchain is
very well maintained.

(In reply to comment #9)
> No, I'm referring to the Inventor code.
I expected this answer.

> If you are aware of any problems with the compiler's PowerPC backend which are
> causing difficulty for Fedora packages,
I am not using Fedora on the PowerPC and am not interested wasting time on
catering a dying niche market (Even Apple dumped the PPC)

> PowerPC toolchain is very well maintained.
FWIW: I am aware about dozens of tiny issues with the powerpc-backend in GCC.
Also, implementation-wise, IMO the rs6000 backend in GCC is amongst the worst
maintained code-bases in GCC at all.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

I am really sickened about these triagers producing nothing but spam and noise -
Stop this non-sense, Mr. Stanley.

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.