https://bugs.openldap.org/show_bug.cgi?id=9530
--- Comment #3 from Howard Chu hyc@openldap.org --- (In reply to norm.green@gemtalksystems.com from comment #2)
This appears to be unnecessary, since there are no functions to modify >ldo_defbinddn after initialization.
Agreed, however the old code is still copying a string pointer to a new location, which is asking for trouble should the pointer is freed in both locations.
There is no such code that ever frees this field. That could be considered a bug in itself, but it's a different bug. While it may be a memory leak we generally don't care about leaks of values that are allocated only once at initialization time and never touched again.