[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: C API draft3: ber_tag_t and LBER_ERROR
"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)
>
> Regradless, 16.4 should clearly state if 32 least significant
> bits or all bits should 1.
>
> Comments?
I believe your definitions are better. Does anyone disagree? I think I
will also add this text following the definitions:
The intent is that LBER_ERROR and LBER_DEFAULT are both defined
as the integer value that has all bits set to 1, as such a value
is not a valid BER tag.
> ...
> - Kurt
>
> PS: the the result of ber_scanf() in decode_example2() is called
> despite possible previous errors and its result isn't checked.
I assume you are talking about the ber_scanf() call that appears right
before ber_free()? I will fix the example code so it looks something
like this:
if ( rc == 0 ) { /* no errors so far */
if (ber_scanf(ber,"}") == LBER_ERROR) {
rc = -1;
}
}
Perhaps a bit cumbersome with the nested if statements, but clear I
think.
Thanks for your helpful comments.
--
Mark Smith
Netscape Communications Corp. / Directory Server Engineering
"Got LDAP?"