Hallvard Breien Furuseth wrote:
> Hello.
Hey, long time no see!
>
> slap_op_time(time_t *t, int *nop) could previously be called with any
> 2 arg of those types. But now it modifies nop[1], so old code other
> than slap_op_time(&op->o_time, &op->o_tincr) gets a bad memory write.
>
> Source-code compat looks like a misfeature now. I'd rather rename and
> re-prototype: slap_op_gettime(Operation* or some new time-struct*).
Sounds like good ideas overall.
> ==
>
> Another fake array: Let's replace bi_op_bind..bi_chk_controls in
> BackendInfo with macros referring into a new bi_op_func[14]. Today
> (&bi->bi_op_bind) is used as an array here: grep -r '(&.*_bind)'
>
> And apply 'contrib/slapd-tools/wrap_slap_ops -u * | patch -p0',
> though that can wait a bit more - until RE24 is really surely not
> going to get new releases and merge conflicts with the patch.
> (Hm. The "delete newlines at EOF" cleanup doesn't belong there.)
>
> Related issue: slap_operation_e was the indexes to (&bi->bi_op_bind),
> but now it has op_txn too corresponding to bi_op_txn with a different
> prototype. 'grep -r op_last' shows code mentioning op_last which has
> not been updated to match this. Unsure what to do about this. Other
> than commenting the enum afterwards, anyway:-)
>
> ==
>
> Any chance of wrapping struct ldapoptions' contents in some structs?
> Today, if a new field is added but the corresponding NULLARG is not
> updated to match, the later NULLARGs initialize the wrong fields and
> can fail. As in ITS#9332 (init ldo_tls_require_san).
Sure. Or whatever can be done to make sure that a missing update causes
a compile-time error instead of being ignorable.
>
> So anyway, one struct per LDAP_blah_NULLARG. Then replace most
> NULLARGs with {0}. But must add lots of macros, for the old fields.
>
> ==
>
> Hallvard
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
