[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?"