Re: C API draft3: ber_tag_t and LBER_ERROR

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

At 08:41 PM 6/20/99 +0200, Hallvard B Furuseth wrote:
>Mark Smith writes:
>>"Kurt D. Zeilenga" wrote:
>>> I am thinking with the advent of ber_tag_t that the LBER_ERROR and
>>> LBER_DEFAULT values may not be set appropriately.  Per 16.4:
>>> 
>>> #define LBER_ERROR      (ber_tag_t) 0xffffffff
>>> #define LBER_DEFAULT    (ber_tag_t) 0xffffffff
>>> 
>>> On a 64-bit system, this is same as:
>>> 
>>> #define LBER_ERROR      (ber_tag_t) 0x00000000ffffffff
>>> #define LBER_DEFAULT    (ber_tag_t) 0x00000000ffffffff
>>> 
>>> I'm thinking that these might macros might be better defined
>>> to all bits 1.
>>> 
>>> #define LBER_ERROR      ((ber_tag_t) ~0)
>>> #define LBER_DEFAULT    ((ber_tag_t) ~0)
>
>That should be ((ber_tag_t) -1).

I prefer (ber_tag_t) ~0.  The standard is defined in terms of
ISO C where (unsigned-type) ~0 is the canonical way of saying
"all bits one".  In my opinion, implementations supporting non-ISO
C are free to define macros such that they are compatible with
the stated requirements.  

>((ber_tag_t) ~0) == 0 with one's complement or sign/magnitude integers.

I would suspect a good compiler on such a platform would generate
an warning.  The following is always false:
	(ber_tag_t) ~0 == (ber_tag_t) 0

>Or use (0 - (ber_tag_t) 1), just in case there are K&R compilers
>where (unsigned long)-1 == (unsigned long)(unsigned int)-1 instead of
>(unsigned long)(long)-1 - I have no idea if that ever happened.

Again, an implementation supporting such a varient of K&R C is
allowed, in my opinion, redefined macros in ways that compatible
with the specification.

>> I believe your definitions are better.  Does anyone disagree?
>Maybe.

>Just a loose thought, but:
>Someone may be depending on these values, since they are there.

Like all the existing code which expects all bits 1....

>Similarly, it may be better to remove the specified values of the
>LDAP_OPT_* constants, to avoid similar problems with these in the
>future.  There is already a conflict with the old UMICH LDAP_OPT_DNS ==
>0x01 == the draft's LDAP_OPT_DESC.

U-Mich LDAP_OPT_* and the draft's LDAP_OPT_* are two differnet
things.  Code using U-Mich LDAP_OPT_* wouldn't compile with draft
headers because the session structure is now opaque.  Code using
the drafts LDAP_OPT_* wouldn't link using U-Mich libraries as
ldap_get/set_option would exist.

I would disagree that the values should be removed.  This would
allow values of LDAP_OPT_API_INFO to differ between implementations
and hence make it impossible to determine which implementation
you were linked to.

I feel the specification should retain specific value requirements
for such macros.

Kurt