On Fri, 22 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
I'm do not follow xHarbour changes any more,
It's quite old code which I still remember,
but I guess you are talking about hb_itemPutCL():
620 if( szText == pItem-item.asString.value )
621 {
622
Hi,
Przemysław Czerpak wrote:
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
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
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 )
Hi,
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
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
On Thu, 21 Jan 2010, Mindaugas Kavaliauskas wrote:
Hi,
BTW, I found code in last commit:
if( * pszFile )
{
char * pszFileName = hb_strdup( pszFile );
if( !hb_storclen_buffer( pszFileName, strlen( pszFileName ), 1 ) )
hb_xfree( pszFileName );
}
else
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!
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(
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! :)
Revision: 13655
http://harbour-project.svn.sourceforge.net/harbour-project/?rev=13655view=rev
Author: druzus
Date: 2010-01-21 00:10:08 + (Thu, 21 Jan 2010)
Log Message:
---
2010-01-21 01:09 UTC+0100 Przemyslaw Czerpak (druzus/at/priv.onet.pl)
*
Hi,
dru...@users.sourceforge.net wrote:
* harbour/src/rtl/itemseri.c
+ added support for hash array flags and default value serialization
Thank You very much!
BTW, I found code in last commit:
if( * pszFile )
{
char * pszFileName = hb_strdup( pszFile );
if(
12 matches
Mail list logo
