Hi,
Przemysław Czerpak wrote:
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.
I'm do not follow xHarbour changes any more, but I guess you are talking
about hb_itemPutCL():
620 if( szText == pItem->item.asString.value )
621 {
622 pItem->item.asString.value[ ulLen ] = '\0';
623 pItem->item.asString.length = ulLen;
624
625 return pItem;
626 }
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.
I guess because in hb_itemPutC() (in Harbour) code:
szText = ( char * ) hb_xmemcpy( hb_xgrab( ulAlloc ), szText, ulAlloc );
is executed before:
hb_itemClear( pItem );
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 );
What about code:
cI := "x127.0.0.1:2941:password:filename"
cI := SUBSTR(cI, 2) // Let's create dynamic string instead of PCODE
NETIO_DECODE(cI,,,,@cI) // I want to reuse cI value for password
Is this code safe in current version of NETIO_DECODE()?
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.
What is another way?
Sometimes I understand, the things that always seemed simple are not such.
Regards,
Mindaugas
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
