hyc(a)symas.com wrote in ITS#8240:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real
> issue is production binaries being built with asserts enabled instead of
> compiling with -DNDEBUG. That's an issue for packagers and distros to resolve.
> Closing this ITS, not an OpenLDAP bug.
Maybe I missed something. But this is the first time I've heard about -DNDEBUG
being mandatory when compiling binary packages for production use. Does it
have other effects?
And what are general rules for assert statements in OpenLDAP code?
In my own (Python) code assert statements are supposed to be only triggered if
something goes wrong *internally* (type issues etc.). If somebody manages to
trigger an assert statement with invalid input from "outside" I always
consider this to be a serious bug revealing insufficient error handling even
though e.g. web2ldap just logs the exception but won't crash. YMMV, but please
I also wonder whether there are more mandatory rules for building packages and
where I can find them.
Please don't get me wrong: My inquiry is in good faith to avoid unnecessary
ITS based on misunderstanding.
I would suggest sending in a patch against master to the -devel list for
For final inclusion if it is approved, see:
--On Monday, June 12, 2017 8:34 PM +0000 Daniel Le <daniel.le(a)exfo.com>
> I've got a chance to write (and test) the code to add API support for
> socket binding addresses.
> Should I send the code diff to this openldap-devel email list for review?
> How to submit a patch request?
> -----Original Message-----
> From: Daniel Le
> Sent: Tuesday, May 16, 2017 6:02 PM
> To: 'openldap-devel(a)openldap.org' <openldap-devel(a)openldap.org>
> Subject: ITS#8654 - Option for LDAP client to bind to a local address
> In reference to the enhancement request ITS#865, please comment on the
> following to add support for binding a local IP address to client socket.
> This is just an outline of changes for one local address. I am not sure
> whether a list of local addresses is necessary. If it is, then a new
> function, similarly to ldap_url_parsehosts, may be written to parse the
> list of local addresses and store them into a linked list. In my use
> case, only one IPv4 or IPv6 local address is used for binding.
> - Modify ldap.h and ldap_set_option to handle the new option
> LDAP_OPT_LOCAL_ADDRESS. Should it be named LDAP_OPT_CLIENT_ADDRESS,
> - Modify struct ldapoptions in ldap-int.h to add element "char
> *ldo_local_address" to hold client local address when
> ldap_set_option(LDAP_OPT_LOCAL_ADDRESS...) is executed. This can char
> pointer can point to an IPv4 address or IPv6 address.
> - ldap_connect_to_host() in os-ip.c
> After the connection socket is created (ldap_int_socket) and before it
> is connected (ldap_pvt_connect), extract the local IP address. If local
> address family (AF_INET/ AF_INET6) matches the one of the host, bind
> socket to the local address.
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
I think it is time to modernise the debug logging a bit, this would make
our life easier when logging and running make (with the copious warnings
compilers will generate unless one passes -Wno-format-extra-args).
The major obstacle to this is the thousands of lines that need
adjusting, luckily there is a tool named Coccinelle, co-developed
with the Linux kernel. It can work with so-called semantic patches and
apply them on a code base to prepare a final patch.
The work so far (that seems to pass the same tests that master does on
loglevel any) is available here:
If you want to replicate the generated patches, you will have to use the
latest version of Coccinelle from git to have them correctly
processed. To help Coccinelle parse OpenLDAP sources, you will also have
to pass "--macro-file-builtins macros.h". You can skip
02-shortcut.cocci, but expect to wait a few days before Coccinelle
processes some of the more if()fy files if you do so.
Sample command line:
spatch --sp-file 01-variadic.cocci --macro-file-builtins macros.h --dir .
If we aim to apply this to master+2.5, we will have the time to
stabilise any unexpected fallout before 2.5 is ready since the resulting
patches are still rather large. It is probably too late to touch 2.4,
however hard it might make to backport any fixes, unless we start to
depend on Coccinelle for backporting just like the Linux kernel does.
I welcome your review and suggestions.
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP