> Not true. They can return non empty value for arrays. > hb_par*() functions accept variable number of parameters which > are used as indexes if corresponding parameter is an array and > exactly in this case it can be array so the behavior of the code > after your modification is unpredictable. Which value will be > used as index depends on platform and calling convention (used ABI). > > IMHO It's time to create separate set of hb_stor*/hb_par* functions > with fixed number of parametrs and without some hidden internal > conversions between types like in hb_parl(). Current situation which > creates problems even for core developers is unacceptable. > I can create basic version and commit it ASAP.
I wanted to suggest that, as current code makes LOTS OF otherwise valid code prone to such errors and unexpected behaviour. Please do. As a next step we will have to convert all our codebase to use the new APIs to avoid such problems. Because of this, probably some very simple sounding API names would be the best here, or, keeping current familiar names and solve compatibility from PP. I'd be very happy if it could be done that way, as I expect majority of current hb_par*() usages don't use the extra optional parameter. Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
