On Thu, 21 Jan 2010, Mindaugas Kavaliauskas wrote: Hi,
> >In this case pszFile points to memory area used by string item in the 1-st > >parameter. It means that: > > hb_storc( pszFile, 1 ); > >may release pszFile before it's used clearing the 1-st item just before > >assign. It's sth like: > > hb_storc( hb_parc( 1 ), 1 ); > Great! :) I should be more careful about such things in my code. In > some cases it is not obvious that we have such situation. Please note that in xHarbour there is protections against code like: hb_storc( hb_parc( 1 ), 1 ); anyhow this protection helps only in such limited situation and it's not general solution so it should not be implemented in core code. The NETIO_DECODE() code clearly shows why, f.e.: hb_storc( pszFile, 1 ); hb_storc( pszServer, 2 ); hb_storni( iPort, 3 ); hb_storni( iTimeOut, 4 ); hb_storclen( pszPasswd, iPassLen, 5 ); hb_storni( iLevel, 6 ); hb_storni( iStrategy, 7 ); it's still not correct though: hb_storc( pszFile, 1 ); is safe. The problem is caused by the unsafe API and any local hack do not help at all because it's exploited by: hb_storclen( pszPasswd, iPassLen, 5 ); It can be resolved in two ways. One of them I used in new string API I recently added where such problems does not exist. Just simply it's enough to call: hb_strfree( hFullName ); after setting all parameters. With such API programmer fully control the life of string buffers himself and does not have to worry that some other code freed or reallocated memory accessible by previously extracted pointers. best regards, Przemek _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
