On Fri, 22 Jan 2010, Mindaugas Kavaliauskas wrote: Hi,
> >But the problem can be exploited if you change the last line of your > >code to: > > NETIO_DECODE(@cI,,,,@cI) > >in such case the reference counter for the string item stored in cI is 1 > >and any assignment to the 1-st or the 5-th parameter can damage both > >pointers previously returned by hb_parc( 1 ) and hb_parc( 5 ). > So, this should be also fixed. NETIO_DECODE(@cI,,,,@cI) sounds a > little nonsense, but it could be result of typo and generate GPF, > corrupt memory, etc. And now we are touching the area which cannot be easy fixed without switching to new API. Such problem can be exploited in many ways. Just simply after each hb_stor*() function or even hb_ret*() if you haven't verified what exactly is modified then you should expect that all pointers to string item buffers or array items or anything like that has been discarded. I.e. hb_itemClear() can activate destructor which will remove or resize some arrays removing the original items or changing the memory addresses of existing items for which you keep pointers retrieved by hb_arrayGetItemPtr() or hb_hashGetItemPtr(). It means that you can find many different similar places in Harbour or Clipper source code where this problem can be exploited. Adding workaround in single place is not a solution. It has to be resolved by alternative API which introduce item protection. Such protection well implemented may give also item write protection in MT mode. Anyhow it will not be Clipper or current Harbour compatible C API. Maybe in the future we will create sth like that. I'm systematically adding new functions like hb_array[SG]et*() or recently added string functions which do not cause such problems for user code or give explicit interface for such protection. Now let's see how we can use it to implement Unicode support. If it's possible in reasonable time to replace all string related functions in the whole Harbour SVN code to work with Unicode items then we can think about replacing also other functions and switching to new API. Harbour is not my fulltime job so I do not want to start global modifications which I cannot finish in reasonable time so it's possible that it will never happen :-( best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
