Hi April,
Viktor Szakáts wrote:
..turns out it's not that easy, so I'm rather waiting :)
IIRC from my quick scan of source and contrib I could not see where
any program used this, but I am probably mistaken.
This can be a problem everywhere where there is
no HB_IS*() call before reading value with hb_par*()
call. Worsened by the undefined nature of va_arg()
when index parameter wasn't passed (which is
99.9% of cases by my guesstimation).
There is also the problem that hb_parc() can return
empty string instead of NULL when an array is passed
and there is no HB_IS*() check. It's a small bug in
that function.
I expect many places where this may cause
instabilities, and all this to support a legacy
feature used very very rarely.
We also miss 'const' modifiers from declarations,
but that's an additional problem.
Same goes to hb_stor*() calls.
When I used this feature it worked but at a terrible performance
cost so I've reverted to a RYO file reader that parses on any one of
three EOL markers.
I'll upload my hbextern sometime this weekend.
Because of the improved handling of EOL and a disconnect between RDD
directories and the current hbextern, the output will have more
entries than the current version.
That's good news.
I've been working with a local copy of hbextern and comparing the
output of the two and with two exceptions the output matches 100%;
the exceptions are: I write the flags controlling the program to the
file header, and the current hbextern finds two entries it should not.
Sounds good also.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
