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