Hi, > I would suggest that if type of string param not is RAW, not use hb_stor*len > use hb_stor* > This would avoid the possible inclusion of terminating null character.
Okay, let's gather these and apply them when we see the bigger picture. Some function may want to return internal zeroes, so we should carefully think about it. Maybe using different C types or something. > I also recommend the use of a new our macro in exclusive HB_TEXT for UNICODE > literals. > Or at least change the current definition of HBTEXT to avoid problems. > > ... > #if defined( UNICODE ) || defined( HB_OS_WIN_CE ) > #define HBTEXT( x ) TEXT( x ) > #else > #define HBTEXT( x ) x > #endif Yes, I thought about it, but from a different context. Such macro should be used to mark all human readable strings/chars in Harbour. When we'll have internal Unicode support. Above macro should rather be named WINTEXT() or U16TEXT(). For current HBTEXT() it doesn't seem good though as we use it to mark some ill. text parameters, which is only needed to be U16 on WinCE, not on UNICODE non-WinCE. > ... > > [ And out of context :) > Remember that in API DLLs, the name of function is finish in A or W. > Not enough that the string is ANSI or UNICODE. ] I'm not sure I understand. I know it's not perfect detection for UNICODE. Now I got the terminology right in source, but if this is a problem I can remove whole autodetection, though I think it's more than nothing and should help in most cases. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
