Re: sb_sasl_write short-count bug?
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.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/