> Viktor Szakáts wrote: >> >> It's just a sort of hunch, since I don't have >> test code and detailed theoretical proof for this, >> but it looks like existing HBQT_QTPTR_FROM_GCPOINTER() >> is a wrong concept and should not be used at all. >> >> It converts GC pointer to a simple one. >> >> In code it's used for some comparisons, but it's >> also stored in object vars, which is very dangerous >> to do as pointer may go invalid anytime, and >> references aren't counted, etcetc. >> >> To me it looks like something to be solved differently >> to avoid GPF time-bombs. >> > > The function is absolutely necessary. > However storing this pointer in an instance variable was wrong. > I fixed it, will be commiting later. For all other purposes > It is used for comparison only.
Thanks. The problem with this function though, is that _anyone can_ mess up internals pretty badly from .prg level if using it without being careful or without having expert knowledge about memory handling internals. 99.99% of Harbour programmers don't have such expertise, and will never have. No one can guarantee that code won't use this, or that it will use it as intended. IOW: It's not safe. I'd suggest to use something else, such functions should not be present in HBQT if we ever want to call it a quality component meant for actual users. I'm sure there are alternative solutions. It's only used in a few places, so even some specific built-in comparison function would do the job nicely. In a generic way this is a time-bomb, and we only have to wait to cause GPF in best case (!) and memory / data corruption in not so lucky cases. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
