[Date Prev][Date Next]
Re: (ITS#5035) Warning patrol
> #1. slapd/frontend.c:frontend_init() has the statement
> if ( slap_known_controls )
> which is always true since slap_known_controls is an array.
> Maybe it should be if ( slap_known_controls )?
> Except... controls.c says slap_known_controls == NULL, which is
> not true - at least not at the time of the if-test above. What's
> that about?
Probably a leftover of a time when slap_known_controls was a pointer
> #2. The return value from op->o_callback->sc_cleanup() is never
> used. Should it be? I noticed because the pcache_op_cleanup()
> function does not return anything. What should it return?
a) ignore it: cleanup could occur too late, when response has already
been returned to client; in this case a return code is there only
because of the standard API
b) handle it: cleanup return code could be usefully returned to caller
if (a), then the return code can be safely ignored
> #3. RE23 struct sync_cookie.rid and struct syncinfo_s.si_rid are
> 'long', but are printed as 'int'. Could change the formats, but -
> any reason not to instead change their types to 'int' as in HEAD?
> I haven't looked at the HEAD syncrepl changes, so I don't know
> what other issues might be involved.
There should be no impact, since they're both limited to 0,999
> #4. bconfig.c: Integer overflow in (1 << (sizeof(int)*8 - 1)) in
> slap_loglevel_get(). If anything else have been trusting signed
> integer overflow to resemble unsigned integers, it's time to cease
> that. The behaviour is undefined, and compilers make use of this
> fact to optimize.
> The loglevel functions are confused about types anyway. They
> collect masks in slap_mask_t, but the API uses an int for the
> Either the API should use slap_mask_t
> or masks should be
> stored in (unsigned) ints. Not for 2.3, I think.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172