Holger Joukl <[EMAIL PROTECTED]> wrote: >> I'm not sure a reinterpret_cast is *ever* a solution. Probably the point >> is where it is assumed that pid_t is int, rather than using pid_t >> directly. > > I first tried to make QValueList<long> work with sip but did not succeed > immediately:-) (will look up how to > do that in the newly released snapshots which should fix this problem). But > above solution obviously works > for me and, as pointed out, int and long are the same for 32 bit compiles > on my machine. > Which makes a QValueList<int> the exact same as a QValueList<long> and > which makes the reinterpret_cast > perfectly valid int this situation. > Imho the solution is ugly because you have to modify *generated* code - but > it is a solution nevertheless.
The fact that "works for you" does not mean that it is a generic enough solution, and that will work also for other platforms. Accessing a QValueList<long> through a QValueList<int>* is a type-aliasing violation, which yields undefined behaviour (under ISO C++). GCC 2.95 does not exploit aliasing to further optimize the code so it does not really matter, but this will probably trigger bogus code generation on newer GCC, when optimizations are turned on. Thus, I expect your patched code to break under Linux where modern compilers are used. I don't know this very issue in detail, so I can't offer a proper solution. It appears to me that if the function KStartupInfoData::pids() is supposed to return a list of pid_t, the better way is to use a QValueList<pid_t>, whatever pid_t is typedef'd to. -- Giovanni Bajo _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde