two functions and convert their return values from
ULONG to long.
Or, even better would be to move to hbSize.
What do you think?
Before you change sth please think about results.
Using Harbour internal types in extended API creates problems
for users who do not well know Harbour internals and want
add some extensions to Harbour, i.e. their own C code or wrappers
to 3-rd party libraries.
ULONG is already a Harbour internal type. It's in fact the
only one, one must use if wanting to use the Extend API.
Swapping that for a clearly Harboury type doesn't seem to
make things worse in my view. But we can as well choose a
standard type, in this case though, I have no idea how to
solve compatibility with size_t and portability (even to
future systems), and our limits are tied to the platform,
not Harbour language (pbly not a huge practical problem
ATM).
As long as they can use well know types then it's rather simple
job. If they have 'int iVal' then they can use hb_retni( iVal ),
if they have long lVal then they can use hb_retnl( lVal ), etc.
True, std type would be the best.
In the moment when we introduce Harbour types to extended API
we are creating problems with casting to types used by other code.
If possible we should use native C types but of course there are
places where we need out own types. String and array indexes are
good candidates for such Harbour dedicated type but it has to be
done globally in all functions not only chosen one. Otherwise we
will make things only worse because we may force some temporary
casting in many different places which later will have to be removed
but without compiler warnings pacified by such temporary casting it
will be hard to locate and clean them.
So, what is your conclusion for this move? I agree it should
be done somehow, question what do we want to convert to and
what steps to make to achieve this?
Pls also remember, we have lots of 'size_t' casts warnings
in Win64, and this may be an opportunity to address them.
We can chose other ways to fix this one, so this issue isn't
top priority.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
