I do not think so. Any code like:
return ( ph && * ph ? * ph : hb_parptr( iParam ) );
is potential source of GPF. If ph is NULL then user passed wrong
parameter.
If *ph is NULL then parameter was freed by QT. In such context using
hb_parptr( iParam )
breaks functionality given by using QPointer class because the fact
that
references were cleared is ignored and code code access wrong memory
area. It can be source of any other unexpected behavior so it's
hard to
analyze your problems because it's possible that they are caused by
above
peace of code.
Has valid concerns but this is how HBQT is implemented from the
inception. I will explain why I call like
return ( ph && * ph ? * ph : hb_parptr( iParam ) );
in a couple of days after committing next which resolves
a lot of concerns. Then probably you would guide me in a right
direction concerning this issue.
This is a very important issue and it should be fixed
if we want to rely on HBQT for serious work. I also suggest
to create RTE when wrong parameter is passed instead of
GC collected pointer of valid kind. It's not really a topic
which should or could be debated. If a library allows to
create GPF just by passing wrong parameter to it, it's wrong
and we never can be sure if a reported GPF is some "real"
error, or "just" a wrongly passed parameter. Not to mention
that wrongly passed parameters can easily signal errors in
other parts of the lib, which makes detection even more
complicated.
Using hb_parptr() when wrong parameter is detected just
makes handling of the problem even more fishy.
An RTE is straightforward though.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
