[Date Prev][Date Next] [Chronological] [Thread] [Top]

BER integer types

The integer types need a lot of cleanup, e.g.
	ber_printf( ber, "b", 1 );
should be
	ber_printf( ber, "b", (ber_int_t) 1 );

Before I start on that, however:

Should I create typedefs ber_enum_t and ber_bool_t as aliases for
ber_int_t, to be used for variables that are sent over the protocol as
enumerations and booleans?  I'd like to, for the sake of readability.

Even though that's overshadowed by the horde of places that use 'int'
to represent the protocol fields because the public API uses int.
Their prototypes should have used ber_int_t instead of int, but that
change isn't one to undertake quite so lightly...
That can break with 32-bit values from the protocol on 16-bit
machines, but OpenLDAP expects 32-bit integers anyway.  At best, if
someone has too much spare time he can insert code to return some
other result code instead of just truncating too large integer values.

Should ldap.h #definitions like LDAP_SCOPE_* and LDAP_DEREF_* use
casts to ber_int_t (or ber_enum_t)?  Safer for use with ber_printf,
but then they cannot be used in #if expressions (except defined()).

The API types are cumbersome to deal with in three places.
How to handle those?

LDAP_F( int )
ldap_parse_sort_control LDAP_P((
	LDAP           *ld,
	LDAPControl    **ctrlp,
	unsigned long  *result,
	char           **attribute ));

LDAP_F( int )
ldap_parse_vlv_control LDAP_P((
	LDAP          *ld,
	LDAPControl   **ctrls,
	unsigned long *target_posp,
	unsigned long *list_countp,
	struct berval **contextp,
	int           *errcodep ));

This is a bit silly, but: What should these functions do if the parsed
unsigned long fields are negative?  Return LDAP_DECODING_ERROR, as if
there was a parse error?  Or should the prototype be changed to take
ber_int_t/ber_enum_t * instead?  (An ASN.1 enum value can be negative.)

And the reverse:

/* structure for virtual list */
typedef struct ldapvlvinfo {
	int             ldvlv_version;
    unsigned long   ldvlv_before_count;
    unsigned long   ldvlv_after_count;
    unsigned long   ldvlv_offset;
    unsigned long   ldvlv_count;
    struct berval *	ldvlv_attrvalue;
    struct berval *	ldvlv_context;
    void *			ldvlv_extradata;

ldap_create_vlv_control() should fail if the user has set one of the
unsigned long fields to a value larger than can be sent over the
protocol.  There will be no need for that if the types are changed to
ber_int_t, unless the function in any case should perform error
checking and fail for negative values.  But I think that can be left
to the server.