Thanks for your comments. Sorry that I was not reacting sooner but I had some family parties to prepare and participate in. > On 23 December 2010 18:55, Andrew Haley wrote: >> On 12/23/2010 03:37 PM, ronny meeus wrote: >> >>> we are changing our compiler from gcc version 2.95.3 to a more recent >>> version (gcc version 3.4.6). >> >> Are you sure about this? This is 2010, nearly 2011. You are changing >> to a 2004 compiler, last updated in 2006. > > I completely agree with Andrew, if you have to update to a newer > compiler you might as well update to a modern version, or you'll just > have to rewrite code again one day. > I have no clue why this compiler was selected. I fully agree that we better would step up to a more recent compiler, but I think this will not solve our problem. >>> What we have observed is that the memory layout of C++ objects with >>> virtual functions has been changed. >> >> This is all to do with the multi-vendor C++ ABI. We had to change gcc >> in order to conform to this. >> >>> Now that we are moving to a newer version, our SW is broken since the >>> virtual table ptr is stored as first entry in the object's memory. >>> As soon as we insert an object in a list, we simply corrupt the VTABLE >>> pointer and the SW soon crashes. >>> >>> Now my questions are: >>> - is there a kind of mode / compiler option to make the new compiler >>> use the old memory layout? >> >> I don't think so. This means we are not lucky here... :-( >> >>> - does somebody know a solution (except rewriting the complete code base) >>> ? >> >> It doesn't sound so terribly hard to fix your macros in order to make >> this correct code. >> >> In addition to the layout problem you're having, (void**)&aptr isn't >> even well-defined C++ and may generate incorect code on recent >> compilers. So, I think you're going to have to clean this up anyway, >> I'm afraid. > > The code was always non-portable, unsafe and incorrect. Someone > really should have noticed it was a problem at some point in the past > decade. > I agree, but the original idea was that these code was used for C only (not C++). Is the code also not correct for C? > Why not just assign to list->next? > You could still do that with a macro if you have some (probably > questionable) reason to avoid templates. > It is a bit more complex than that. The name of the member is not always "next". We take only the assumption that the next pointer is the first member of the structure / class and then we cast it in the macro to a void pointer. We cannot use templates since the code is both used for C and C++ code. Best regards Ronny
