* source/rtl/hbinet.c * HB_SOCKET_STRUCT renamed to HB_SOCKET. + Added PHB_SOCKET type. + Added hb_selectReadFD(), hb_selectWriteFD() which are similar to hb_selectReadSocket() and hb_selectWriteSocket() but expect raw FD plus explicit timeout values. These function names and solutions are tentative to solve SSL integration with Harbour, and hopefully in the future we will have a clean net API, the current one is very messy.The above modification made internal inet structure public. I do not remember that we ever decide that it's official Harbour inet API. I'm working on new socket library but it does not have any public HB_SOCKET and I do not plan to introduce anything like that. Now I do not know if it's sense to continue this job. Can we agree what is our goal for Harbour socket API?
Since the current one is a very ugly mess, I'd vote for your new implementation. As I wrote in the entry, this move was tentative, the published structure as well, and of course it'd be better not to publish such structure at all, however I needed it to move along with SSL. For SSL, low-level 'select()' functionality is required to solve timeouts with blocking sockets. The problems with current Harbour level inet API and implementation are many, I started to write an e-mail about it, but dropped it. My first impression was that it uses literally *all* possible ways to return values and signal errors, without too much consistency. I also doesn't seem to be thread safe. Plus lack of low-level API is a problem.
* source/vm/itemapi.c ! hb_itemPutCPtr(), hb_itemPutCLPtr() fixed to put empty string to item if szText is NULL and length is non-zero, instead of trying to free NULL pointer causing internal error.It was never legal to call these functions with NULL pointers. We can define such functionality as legal but in such case your modifications have to be changed: if( ulLen == 0 || szText == NULL ) in hb_itemPutCPtr() is redundant and: if( ulLen == 0 ) is enough and in hb_itemPutCLPtr(): pItem->item.asString.length = ulLen; if( ulLen == 0 || szText == NULL ) { pItem->item.asString.allocated = 0; pItem->item.asString.value = ( char * ) ""; if( szText ) hb_xfree( szText ); } have to be fixed to set valid string size because no corrupted items are created when szText is NULL and ulLen > 0 so it should be: if( szText == NULL ) ulLen = 0; pItem->item.asString.length = ulLen; if( ulLen == 0 ) { pItem->item.asString.allocated = 0; pItem->item.asString.value = ( char * ) ""; if( szText ) hb_xfree( szText ); } Anyhow I do not find such modification as good idea. IMHO passing NULL pointers to hb_itemPutC[L]Ptr() should be forbidden because usually it's result of some mistake in calling code so previous code which caused GPF and allow to easy find and fix potential problem was better but it's only my personal preference so I can accept also extended hb_itemPutC[L]Ptr() behavior though accepting code like: hb_itemPutCLPtr( pItem, NULL, 100 ); looks strange for me.
Please feel free to correct it as you feel best, it's possible that I've overlooked something. [ I have no code dependent on it such behavior. ] Brgds, Viktor _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
