Michael B Allen wrote:
Hi,
Consider the sb_sasl_write function:
341 static ber_slen_t 342 sb_sasl_write( Sockbuf_IO_Desc *sbiod, void *buf, ber_len_t len) 343 {<snip> 352 /* Are there anything left in the buffer? */ 353 if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { 354 ret = ber_pvt_sb_do_write( sbiod, &p->buf_out ); <snip> 391 ret = ber_pvt_sb_do_write( sbiod, &p->buf_out ); 392 393 /* return number of bytes encoded, not written, to ensure 394 * no byte is encoded twice (even if only sent once). 395 */ 396 return len; 397 }
This optimistically returns the len supplied. If ber_pvt_sb_do_write returns a short-count then data will be left in the p->buf_out. The remaining data will not be written until the next sb_sasl_write call which may not happen. I have not observed a problem but just from examining the logic I thought I might say something.
Is this bug?
Would putting ber_pvt_sb_do_write in a loop do any good?
Pretty sure we discussed that approach once in the past (check CVS or the -devel list archive). The conclusion is that it's up to the caller to loop if they want to.
As for the next write not happening - well, obviously this hasn't been a problem thus far. I suppose one way to really fix this is to check the buffer status and decrement len if the output buffer isn't empty yet. Then the caller will always know it has to come back to complete the write.