Daniel Stenberg <[EMAIL PROTECTED]> writes: > On Fri, 26 Jan 2007, Daniel Stenberg wrote: > >> I think I like this idea. It would also make it clearly which functions that >> would work non-blocking since we'd only implement those that truly are... > > Ok, let's say I take that approach for functions that currently return > pointers and not just return status integers. > > But what do you think about the functions that a) don't need adjustments > (since they already return ints and we can just introduce a new error code > meaning EAGAIN - that's what I've done so far)
That means all callers needs adjustments, since it has to handle EAGAIN return values, which IMHO pretty much amounts to changing the API. I think it would still be useful to have two functions even in this case. One blocking and one non-blocking. It is generally a pain to write code to handle asynchronous events. If there is an API that is simple and blocking, that will probably be good enough for many (if not most) applications. I don't see doubling the number of APIs to support non-blocking operation as a real problem. I think doubling the APIs lead to clarity about which functions are blocking and which are not. > or b) just require a minor change like libssh2_sftp_read() that > simply needs to return a signed variable instead of the current > size_t ? > > libssh2_sftp_read() might need attention anyway since it is documented to > return -1 on error which is hard to do on unsigned variables, and because the > normal read() returns ssize_t and I think this should mimic that. Yup, that sounds simply like a bug that should be fixed. In general, I'd like to see all the string lengths be 'size_t' instead of 'unsigned int' or 'unsigned long' too... however, I didn't start on that since it typically ends up changing the entire code base, and ultimately the APIs too, something I didn't want to do in my first commit. /Simon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ libssh2-devel mailing list libssh2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-devel
