Re: LDAP C API: Data Types and Legacy Implementations

[Hallvard B Furuseth <h.b.furuseth@usit.uio.no>]

Kurt D. Zeilenga wrote:
> I suggest that a new type be introduced:
> 
>         typedef impl-specific-int ber_int_t; /* at least 32-bits */

Add ber_uint_t as well with the same size; it's common to convert
between signed and unsigned for a type.  Or use
	#define ber_int_t impl-specific-int
so we can use the type `unsigned ber_int_t'.

#

We need a way to printf() and sscanf() these types.
Before `long long' arrived, we could use
    printf("%ld", (long)var);
and
    scanf("%ld", &long_var); var = long_var;
but no more.  size_t (which seems like the natural choice for int_len_t)
can be larger than long, and the next C standard will apparently bless
this practice.

Solutions:

a) require that the types are no larger than long.
   It limits the size of LDAP objects unnecessarily, it's no problem for
   the application (it can just cast things to long), but the library
   might need some #ifdef tests to check if size_t <= u.long.

or

b) provide format macros for printing and reading each type, similar to
   C9X <inttypes.h>:
   	#define LBER_PRI_LEN_T	"l"
	#define LBER_SCN_LEN_T	"l"
	#define LBER_PRI_TAG_T  ""
	...
	printf("%" LBER_PRI_LEN_T "x", (ber_len_t) length);
   That provides finer tuning but big code, and a portable library will
   also have to run a lot more configuration tests to find the right
   definitions.

#

I don't quite see what the new type ber_tag_t gives us when we don't
know the mapping between (class,encoding,tag-value) tuples and ber_tag_t
values.  (Well, we know that CLASS and ENCODING must always be in the
low octet, otherwise most code which tests them will fail).

So I suggest to either add:
	unsigned long lber_tag_t_to_value(ber_tag_t)
    and
	ber_tag_t     lber_value_to_tag_t(unsigned long)

or: that the mapping between ber_tag_t and (class,encoding,tag-value) is
defined in the draft -- I suggest to read it as a raw integer from the
network with the least significant byte first; that way the bitmask
0xe0 will extract the encoding and class even for multi-octet tags.

-- 
Hallvard