Re: C API draft3: ber_tag_t and LBER_ERROR

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

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).
((ber_tag_t) ~0) == 0 with one's complement or sign/magnitude integers.
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.

>> Regradless, 16.4 should clearly state if 32 least significant
>> bits or all bits should 1.

Avoid talk of bits, for the reason above.

>> Comments?
> 
> 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.  It may
be better to leave the values unspecified: just say that they are not
valid tag values (and probably that they are nonzero and equal).  That
will emphasize more clearly that return codes from ber_scanf & co need
to be checked the right way.  After all, most code will have to be
examined in any case to check the new return types and argument types.

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.

-- 
Hallvard