On Mon, 28 Dec 2009, vszak...@users.sourceforge.net wrote:
Hi,
> ; TOFIX:
> va_end() has been commented for all platforms, although
> it's required by all documentation I could verify.
> If this causes problems for specific platforms/compilers,
> we should only add this hack for those targets, and only
> when HB_TR_WINOUT is enabled.
This va_end() is my copy and past mistake and should be fixed by
removing it. Looks that we do not use C compiler which tries to
validate va_start()/va_end() usage by C preprocessor rules.
hb_xgrab() inside hb_snprintf() can be activated only when more
then 16 '%' patterns is used inside formatted strings so it's rather
very seldom situation. I do not think that we have such messages
anyhow it's possible that someone will want to use sth like that.
In such case it creates problems only when fm.c is compiled with
HB_TR_DEBUG what is also rather seldom situation. The problem
is that current protection against recursive calls causes that
log messages are silently ignored in MT mode. I do not think
that it's worth to introduce any non local hacks for windows
only debugging in this code so probably as the easiest hack we
can simply check if the memory statistic module is enabled and
were compiled with HB_TR_DEBUG messages using new function like:
if( hb_xtraced() )
and if yes then the number of non double '%' characters in format
string. If it's greater then 16 we can simply generate message
about it instead of original one with suggestion to divide the
trace log message to use less then 16 parameters.
Please note that we rather need new function like hb_xtraced() instead
of adding sth like hb_xquery( HB_MEM_TRACED ). Anyhow if if want
to use HB_MEM_TRACED then please remember that you have to add code
which will make:
if( iMode == HB_MEM_TRACED )
{
return ...;
}
before HB_TRACE() message inside hb_xquery().
There was never problem with parameters passed to HB_TRACE()
massages in code like:
HB_TRACE( HB_TR_DEBUG, ( "new_QApplication %i B %i KB",
( int ) hb_xquery( 1001 ), hbqt_getmemused() ) );
so this part can be ignored but there is a problem with this code:
TCHAR lpOutputString[ 2048 ];
MultiByteToWideChar( CP_ACP, 0, buffer2, -1,
lpOutputString, sizeof( lpOutputString ) );
OutputDebugString( lpOutputString );
It's potential buffer overflow bug because MultiByteToWideChar()
needs as parameter size of buffer in characters not in bytes though
doubled buffered size reduce it - probably even eliminate it because
I do not think that languages which double number of characters in
unicode representation exists anyhow I strongly suggest to clean this
code and change it to:
TCHAR lpOutputString[ 1024 ];
MultiByteToWideChar( CP_ACP, 0, buffer2, -1, lpOutputString, 1024 );
OutputDebugString( lpOutputString );
HTH
best regards,
Przemek
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
