Re: C API draft3: ber_tag_t and LBER_ERROR

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

Kurt D. Zeilenga writes:
> The following is always false:
> 	(ber_tag_t) ~0 == (ber_tag_t) 0

Nope.  The (ber_tag_t) cast converts the argument's _value_, not its
_bit representation_, to ber_tag_t.  The _value_ of signed ~0 is zero on
a one's complement machine.  (I was too hasty to say it's 0 on
sign/magnitude; then the value is INT_MIN.)

So --

> I prefer (ber_tag_t) ~0.

That's wrong.

>> 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.

No, a (ber_tag_t)~0 specification says the machine's LBER_ERROR *is*
zero.

>> 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....

Code like
	if ( ber_scanf(...) == -1 )
expets a _value_ of -1, not any particular bit pattern.

But that _is_ a problem with code which sends a <signed something*>
pointer to a routine which treats it as <unsigned something*> or vice
versa, or similar with a signed argument to a varargs function which
treats it as an unsigned argument.  Or to a such function without a
prototype, as in K&R.  Fortunately, LBER_ERROR is seldom, if ever, sent
as an argument.

>> 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.

True enough.  I was thinking of the transition phase when both existed;
that did cause trouble.  Still,

> I would disagree that the values should be removed.

Fine by me, it was just a thought.

-- 
Hallvard