Hi Alex,
I see you made this change to win_prt.c in WIN_PORTREAD:lpBuffer = ( char * ) hb_xgrab( dwNumberOfBytesToRead + 1 ); and: if( ! hb_storclen_buffer( lpBuffer, dwNumberOfBytesRead, 2 ) ) where I originally coded something like: lpBuffer = ( char * ) hb_xgrab( dwNumberOfBytesToRead ); and: hb_storclen(lpBuffer, NumberOfBytesRead, 2); You said in the ChangeLog: ! Fixed buffer sizes, after valgrind test. (off by one bugs. hb_storclen_buffer()/hb_retclen_buffer() need one byte extra above the size returned, in order to hold the EOS char) The Clipper NG says:Since _storclen() allows you to specify an explicit logical length forthe character value, the string you supply does not need to be null-terminated and may safely contain embedded null bytes.How come we need to allocate a buffer bigger by 1? Is it because you wanted to use hb_storclen_buffer which does not need an hb_xfree and is a bit different from hb_storclen?
Yes, exactly. Please remember that C level hb_* functions are never meant to be fully Clipper compatible. They are usually similar, but Harbour makes no guarantee they are same. The Clipper compatibility functions are called the same as in Clipper: _*(), like _storc(). But, in this case the situation is less theoretic because hb_storclen_buffer() doesn't have an equivalent in Clipper at all. This is an optimized version of hb_storclen() and it will require the allocation of the string buffer by the user (the idea is that many times such buffer is already allocated in some case anyway). Since this buffer will be used internally by HVM as is, the extra 1 byte also needs to be allocated by user, to make space for an EOS char. [ The other important aspect of hb_storclen_buffer() usage is that it may fail if the Harbour parameter wasn't passed by ref. In this case the buffer should be freed by caller. ] Brgds, Viktor _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
