Re: ldap_err2string format

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

At 03:54 PM 6/16/00 -0600, Dave Steck wrote:
>According to <draft-ietf-ldapext-ldap-c-api-04.txt>, the output of ldap_err2string(err) is:
>  "an informative zero-terminated character string message describing the error."
>It doesn't specify whether the string is encoded in UTF-8 or may be local, such as DBCS.

I believe ldap_err2string(err) is intended to behave much
like strerror(err).  I would suggest using language similar
to that found in the Standard C Library specification.

Synopsis
   char *ldap_err2string(err);

Description
   The ldap_err2string function maps the LDAP result code in
   err to an message string.  The implementation behaves as if no
   library calls the ldap_err2string function.

Returns
   The ldap_err2string function returns a pointer to the string,
   the contents of which are implementation-defined.  The array
   pointed to shall not be modified by the program, but may be
   overwritten by a subsequent call to the ldap_err2string
   function.

Of course, like strerror(), ldap_err2string is not thread safe.
This may be cause to alter the last sentence,
  s/, but may/and must not/

>The draft says:
>So what do you think?

I believe the UTF-8/T.61 requirement should only apply to
strings which are to carried over LDAP.  Other strings,
such as host names and error texts, should be C strings.

> Does the spec nail this down to UTF-8 (in LDAPv3)?

No, and it shouldn't.

 char *s = ldap_err2string( ldap_get_option( NULL, -1, NULL ) );

Is the returned string UTF-8, T.61, or a C string?
It cannot depend on the protocol in use as a protocol version
has yet to specified.  The encoding should not be protocol
dependent, it should be language dependent.

>If [UTF-8], the common coding practice of:
>   printf(".... %s\n", ldap_err2string(err));
>is ill advised since it's not internationalized.

Exactly.  Note that this practice is assumed valid given
the I-D examples.

Kurt