>> It has nothing to anything. It works just like standard methods >> though it's a less efficient due to one additional function stack >> frame which is created during execution of inline methods so >> the memory alignment is a little bit different and it can interact >> with some buggy code which access non initialized memory or use >> wrong pointers or even keep some indirect references to function >> methods in C structures. >> > > This very well illustrates the problem. > Soo it means somewhere, may be at deep levels, > ACCESS/ASSIGN ... INLINE ... > has some differences with regular method calls. > > I am just asking, which ChangeLog entry after 15 Mar > highlighted this difference. It is only for informative purposes. > > Based on this alone, I am about to remove a lot of INLINE calls > from hbXBP.
While dropping INLINE is good idea for performance, it's very wrong idea to fix GPF by changing the code.... I can't repeat that enough, but seemingly without any reception on the other end :( I can't reckon why you find it a good idea to fix GPF by introducing kludges on the .prg level... > True. But my code was not buggy at all. > It just worked as I explained and all of a sudden it stopped working > without even changing a line in the code. I am simply trying to > figure out 'what caused it'. > > I already told, I have removed all calls to inline access/assign and > everything is working fine without changing anything in other C code. Which proves nothing. If your code can build on Linux, just run valgrind on it and post the results. You can find the exact details in INSTALL about using valgrind. Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
