Re: ber_printf's return type in the C API

[Mark Smith <mcs@netscape.com>]

Unless I missed it, the current draft only requires that "ber_printf()
returns -1 if there is an error during encoding and a positive number if
successful."  Therefore, it is okay to leave the return type as int.  Is
it important for the caller to know how many octets were output?  I
don't think so myself.  If that functionality is required though, we
will need to do something about the ber_printf() return value.

I do agree that the text should be changed to say "... a non-negative
number if successful" and also in section 9 paragraph 1.  Good catch!

-- 
Mark Smith
iPlanet Directory Architect / Sun-Netscape Alliance
My words are my own, not my employer's.   Got LDAP?


Hallvard B Furuseth wrote:
> 
> Yet Another API Nitpick...
> 
> As far as I can tell, ber_printf() usually returns the number of octets
> written from the last parameter, or -1 on error.  Implementations that
> want to do that reliably will need the return type of ber_printf to be
> "signed ber_len_t" (OpenLDAP calls it ber_slen_t) instead of int,
> otherwise they can't output objects with more than MAX_INT octets.
> (They still can't print objects whose size is in the range
> <max(ber_slen_t),max(ber_len_t)], though.)
> 
> Personally I don't care, but I imagine it could matter to whoever it was
> who insisted that we can't give ber_printf and ber_scanf the same error
> return (and return type), because it breaks backwards compatibility.
> 
> BTW, ber_printf(ber,"") returns 0 on the implementations I have seen.
> This violates the clain "ber_printf() returns ... a positive number if
> successful", it should be "nonnegative".  The same goes for the
> "positive" error codes in section 9 paragraph 1.
> 
> --
> Hallvard