OK. Is more cleaner.
An another issue is I think is in hbtrace.c with the following line:
MultiByteToWideChar( CP_ACP, 0, hb_strncpy( message, buf.psz, sizeof(
message ) - 1 ), -1,
buf.lp, HB_SIZEOFARRAY( buf.lp ) );
The strncpy( message, buf.psz, sizeof( message ) - 1 ) can lead into a
recursive HB_TRACE call, as it happened in one of my test case.
Best regards,
István
-----Original Message-----
From: harbour-boun...@harbour-project.org
[mailto:harbour-boun...@harbour-project.org] On Behalf Of Przemyslaw Czerpak
Sent: 2010. január 4. 18:09
To: Harbour Project Main Developer List.
Subject: Re: RE: RE: [Harbour] SF.net SVN: harbour-project:[13444] trunk/harbour
On Mon, 04 Jan 2010, Bisz István wrote:
> OK. Maybe I was too happy to see this message, sorry.
Ups. I've just seen that it was not always shown but only
when //INFO were used so it's fine for me. I only suggest
to replace:
hb_snprintf( buffer, sizeof( buffer ),
HB_I_("Memory allocated but not released: none") );
hb_conOutErr( buffer, 0 );
with simple:
hb_conOutErr( HB_I_("Memory allocated but not released: none"), 0 );
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
